draft-thornburgh-adobe-rtmfp-02.txt   draft-thornburgh-adobe-rtmfp-03.txt 
Network Working Group M. Thornburgh Network Working Group M. Thornburgh
Internet-Draft Adobe Internet-Draft Adobe
Intended status: Informational January 28, 2013 Intended status: Informational February 12, 2013
Expires: August 1, 2013 Expires: August 16, 2013
Adobe's Secure Real-Time Media Flow Protocol Adobe's Secure Real-Time Media Flow Protocol
draft-thornburgh-adobe-rtmfp-02 draft-thornburgh-adobe-rtmfp-03
Abstract Abstract
This memo describes the Secure Real-Time Media Flow Protocol (RTMFP), This memo describes the Secure Real-Time Media Flow Protocol (RTMFP),
an endpoint-to-endpoint communication protocol designed to securely an endpoint-to-endpoint communication protocol designed to securely
transport parallel flows of real-time video, audio, and data transport parallel flows of real-time video, audio, and data
messages, as well as bulk data, over IP networks. RTMFP has features messages, as well as bulk data, over IP networks. RTMFP has features
making it effective for peer-to-peer (P2P) as well as client-server making it effective for peer-to-peer (P2P) as well as client-server
communications, even when Network Address Translators (NATs) are communications, even when Network Address Translators (NATs) are
used. used.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 1, 2013. This Internet-Draft will expire on August 16, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 4 skipping to change at page 3, line 4
2.3.11.1.2. Return Flow Association . . . . . . . . . . . 32 2.3.11.1.2. Return Flow Association . . . . . . . . . . . 32
2.3.12. Next User Data Chunk . . . . . . . . . . . . . . . . . 33 2.3.12. Next User Data Chunk . . . . . . . . . . . . . . . . . 33
2.3.13. Data Acknowledgement Bitmap Chunk (Bitmap Ack) . . . . 35 2.3.13. Data Acknowledgement Bitmap Chunk (Bitmap Ack) . . . . 35
2.3.14. Data Acknowledgement Ranges Chunk (Range Ack) . . . . 37 2.3.14. Data Acknowledgement Ranges Chunk (Range Ack) . . . . 37
2.3.15. Buffer Probe Chunk . . . . . . . . . . . . . . . . . . 39 2.3.15. Buffer Probe Chunk . . . . . . . . . . . . . . . . . . 39
2.3.16. Flow Exception Report Chunk . . . . . . . . . . . . . 39 2.3.16. Flow Exception Report Chunk . . . . . . . . . . . . . 39
2.3.17. Session Close Request Chunk (Close) . . . . . . . . . 40 2.3.17. Session Close Request Chunk (Close) . . . . . . . . . 40
2.3.18. Session Close Acknowledgement Chunk (Close Ack) . . . 40 2.3.18. Session Close Acknowledgement Chunk (Close Ack) . . . 40
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2. Endpoint Identity . . . . . . . . . . . . . . . . . . . . 42 3.2. Endpoint Identity . . . . . . . . . . . . . . . . . . . . 43
3.3. Packet Multiplex . . . . . . . . . . . . . . . . . . . . . 43 3.3. Packet Multiplex . . . . . . . . . . . . . . . . . . . . . 44
3.4. Packet Fragmentation . . . . . . . . . . . . . . . . . . . 44 3.4. Packet Fragmentation . . . . . . . . . . . . . . . . . . . 44
3.5. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.5. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5.1. Startup . . . . . . . . . . . . . . . . . . . . . . . 46 3.5.1. Startup . . . . . . . . . . . . . . . . . . . . . . . 47
3.5.1.1. Normal Handshake . . . . . . . . . . . . . . . . 46 3.5.1.1. Normal Handshake . . . . . . . . . . . . . . . . 47
3.5.1.1.1. Initiator . . . . . . . . . . . . . . . . . . 47 3.5.1.1.1. Initiator . . . . . . . . . . . . . . . . . . 48
3.5.1.1.2. Responder . . . . . . . . . . . . . . . . . . 49 3.5.1.1.2. Responder . . . . . . . . . . . . . . . . . . 50
3.5.1.2. Cookie Change . . . . . . . . . . . . . . . . . . 51 3.5.1.2. Cookie Change . . . . . . . . . . . . . . . . . . 52
3.5.1.3. Glare . . . . . . . . . . . . . . . . . . . . . . 52 3.5.1.3. Glare . . . . . . . . . . . . . . . . . . . . . . 53
3.5.1.4. Redirector . . . . . . . . . . . . . . . . . . . 53 3.5.1.4. Redirector . . . . . . . . . . . . . . . . . . . 54
3.5.1.5. Forwarder . . . . . . . . . . . . . . . . . . . . 54 3.5.1.5. Forwarder . . . . . . . . . . . . . . . . . . . . 55
3.5.1.6. Redirector and Forwarder with NAT . . . . . . . . 55 3.5.1.6. Redirector and Forwarder with NAT . . . . . . . . 57
3.5.2. Congestion Control . . . . . . . . . . . . . . . . . . 58 3.5.2. Congestion Control . . . . . . . . . . . . . . . . . . 60
3.5.2.1. Retransmission Timeout . . . . . . . . . . . . . 58 3.5.2.1. Time Critical Reverse Notification . . . . . . . 60
3.5.2.2. Burst Avoidance . . . . . . . . . . . . . . . . . 61 3.5.2.2. Retransmission Timeout . . . . . . . . . . . . . 61
3.5.3. Address Mobility . . . . . . . . . . . . . . . . . . . 61 3.5.2.3. Burst Avoidance . . . . . . . . . . . . . . . . . 63
3.5.4. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.5.3. Address Mobility . . . . . . . . . . . . . . . . . . . 64
3.5.4.1. Keepalive . . . . . . . . . . . . . . . . . . . . 62 3.5.4. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.5.4.2. Address Mobility . . . . . . . . . . . . . . . . 62 3.5.4.1. Keepalive . . . . . . . . . . . . . . . . . . . . 65
3.5.4.3. Path MTU Discovery . . . . . . . . . . . . . . . 63 3.5.4.2. Address Mobility . . . . . . . . . . . . . . . . 65
3.5.5. Close . . . . . . . . . . . . . . . . . . . . . . . . 63 3.5.4.3. Path MTU Discovery . . . . . . . . . . . . . . . 66
3.6. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.5.5. Close . . . . . . . . . . . . . . . . . . . . . . . . 66
3.6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 64 3.6. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.6.1.1. Identity . . . . . . . . . . . . . . . . . . . . 64 3.6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 67
3.6.1.2. Messages and Sequencing . . . . . . . . . . . . . 65 3.6.1.1. Identity . . . . . . . . . . . . . . . . . . . . 67
3.6.1.3. Lifetime . . . . . . . . . . . . . . . . . . . . 66 3.6.1.2. Messages and Sequencing . . . . . . . . . . . . . 68
3.6.2. Sender . . . . . . . . . . . . . . . . . . . . . . . . 67 3.6.1.3. Lifetime . . . . . . . . . . . . . . . . . . . . 69
3.6.2.1. Startup . . . . . . . . . . . . . . . . . . . . . 68 3.6.2. Sender . . . . . . . . . . . . . . . . . . . . . . . . 70
3.6.2.2. Queuing Data . . . . . . . . . . . . . . . . . . 68 3.6.2.1. Startup . . . . . . . . . . . . . . . . . . . . . 71
3.6.2.3. Sending Data . . . . . . . . . . . . . . . . . . 69 3.6.2.2. Queuing Data . . . . . . . . . . . . . . . . . . 71
3.6.2.3.1. Startup Options . . . . . . . . . . . . . . . 71 3.6.2.3. Sending Data . . . . . . . . . . . . . . . . . . 72
3.6.2.3.2. Send Next Data . . . . . . . . . . . . . . . 71 3.6.2.3.1. Startup Options . . . . . . . . . . . . . . . 74
3.6.2.4. Processing Acknowledgements . . . . . . . . . . . 71 3.6.2.3.2. Send Next Data . . . . . . . . . . . . . . . 74
3.6.2.5. Negative Acknowledgement and Loss . . . . . . . . 72 3.6.2.4. Processing Acknowledgements . . . . . . . . . . . 74
3.6.2.6. Timeout . . . . . . . . . . . . . . . . . . . . . 73 3.6.2.5. Negative Acknowledgement and Loss . . . . . . . . 75
3.6.2.7. Abandoning Data . . . . . . . . . . . . . . . . . 74 3.6.2.6. Timeout . . . . . . . . . . . . . . . . . . . . . 76
3.6.2.7.1. Forward Sequence Number Update . . . . . . . 74 3.6.2.7. Abandoning Data . . . . . . . . . . . . . . . . . 77
3.6.2.8. Examples . . . . . . . . . . . . . . . . . . . . 74 3.6.2.7.1. Forward Sequence Number Update . . . . . . . 77
3.6.2.9. Flow Control . . . . . . . . . . . . . . . . . . 76 3.6.2.8. Examples . . . . . . . . . . . . . . . . . . . . 77
3.6.2.9.1. Buffer Probe . . . . . . . . . . . . . . . . 77 3.6.2.9. Flow Control . . . . . . . . . . . . . . . . . . 79
3.6.2.10. Exception . . . . . . . . . . . . . . . . . . . . 77 3.6.2.9.1. Buffer Probe . . . . . . . . . . . . . . . . 80
3.6.2.11. Close . . . . . . . . . . . . . . . . . . . . . . 77 3.6.2.10. Exception . . . . . . . . . . . . . . . . . . . . 80
3.6.3. Receiver . . . . . . . . . . . . . . . . . . . . . . . 78 3.6.2.11. Close . . . . . . . . . . . . . . . . . . . . . . 80
3.6.3.1. Startup . . . . . . . . . . . . . . . . . . . . . 79 3.6.3. Receiver . . . . . . . . . . . . . . . . . . . . . . . 81
3.6.3.2. Receiving Data . . . . . . . . . . . . . . . . . 80 3.6.3.1. Startup . . . . . . . . . . . . . . . . . . . . . 82
3.6.3.3. Buffering and Delivering Data . . . . . . . . . . 82 3.6.3.2. Receiving Data . . . . . . . . . . . . . . . . . 83
3.6.3.4. Acknowledging Data . . . . . . . . . . . . . . . 84 3.6.3.3. Buffering and Delivering Data . . . . . . . . . . 85
3.6.3.4.1. Timing . . . . . . . . . . . . . . . . . . . 84 3.6.3.4. Acknowledging Data . . . . . . . . . . . . . . . 87
3.6.3.4.2. Size and Truncation . . . . . . . . . . . . . 85 3.6.3.4.1. Timing . . . . . . . . . . . . . . . . . . . 87
3.6.3.4.3. Constructing . . . . . . . . . . . . . . . . 85 3.6.3.4.2. Size and Truncation . . . . . . . . . . . . . 88
3.6.3.4.4. Delayed Acknowledgement . . . . . . . . . . . 86 3.6.3.4.3. Constructing . . . . . . . . . . . . . . . . 88
3.6.3.4.5. Obligatory Acknowledgement . . . . . . . . . 86 3.6.3.4.4. Delayed Acknowledgement . . . . . . . . . . . 89
3.6.3.4.6. Opportunistic Acknowledgement . . . . . . . . 87 3.6.3.4.5. Obligatory Acknowledgement . . . . . . . . . 89
3.6.3.4.7. Example . . . . . . . . . . . . . . . . . . . 87 3.6.3.4.6. Opportunistic Acknowledgement . . . . . . . . 90
3.6.3.5. Flow Control . . . . . . . . . . . . . . . . . . 88 3.6.3.4.7. Example . . . . . . . . . . . . . . . . . . . 90
3.6.3.6. Receiving a Buffer Probe . . . . . . . . . . . . 89 3.6.3.5. Flow Control . . . . . . . . . . . . . . . . . . 91
3.6.3.7. Rejecting a Flow . . . . . . . . . . . . . . . . 90 3.6.3.6. Receiving a Buffer Probe . . . . . . . . . . . . 92
3.6.3.8. Close . . . . . . . . . . . . . . . . . . . . . . 90 3.6.3.7. Rejecting a Flow . . . . . . . . . . . . . . . . 93
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91 3.6.3.8. Close . . . . . . . . . . . . . . . . . . . . . . 93
5. Security Considerations . . . . . . . . . . . . . . . . . . . 91 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 94
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 92 5. Security Considerations . . . . . . . . . . . . . . . . . . . 94
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 92 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 95
7.1. Normative References . . . . . . . . . . . . . . . . . . . 92 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.2. Informative References . . . . . . . . . . . . . . . . . . 93 7.1. Normative References . . . . . . . . . . . . . . . . . . . 95
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 93 7.2. Informative References . . . . . . . . . . . . . . . . . . 96
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 96
1. Introduction 1. Introduction
Adobe's Secure Real-Time Media Flow Protocol (RTMFP) is intended for Adobe's Secure Real-Time Media Flow Protocol (RTMFP) is intended for
use as an endpoint-to-endpoint data transport service in IP networks. use as an endpoint-to-endpoint data transport service in IP networks.
It has features that make it well suited to the transport of real- It has features that make it well suited to the transport of real-
time media (such as low-delay video, audio, and data) as well as bulk time media (such as low-delay video, audio, and data) as well as bulk
data, and for client-server as well as peer-to-peer (P2P) data, and for client-server as well as peer-to-peer (P2P)
communication. These features include independent parallel message communication. These features include independent parallel message
flows which may have different delivery priorities, variable message flows which may have different delivery priorities, variable message
skipping to change at page 9, line 26 skipping to change at page 9, line 26
bool_t more :1; bool_t more :1;
uintn_t digit :7; uintn_t digit :7;
value = (value * 128) + digit; value = (value * 128) + digit;
} while(more); } while(more);
} :variable*8; } :variable*8;
+-------------/-+ +-------------/-+
| \ | | \ |
+-------------/-+ +-------------/-+
VLU depiction in following figures Figure 1: VLU depiction in following diagrams
Unless stated otherwise in this specification, implementations SHOULD Unless stated otherwise in this specification, implementations SHOULD
handle VLUs encoding unsigned integers at least 64 bits in length handle VLUs encoding unsigned integers at least 64 bits in length
(that is, encoding a maximum value of at least 2^64 - 1). (that is, encoding a maximum value of at least 2^64 - 1).
2.1.3. Option 2.1.3. Option
An Option is a Length-Type-Value triplet. Length and Type are An Option is a Length-Type-Value triplet. Length and Type are
encoded in VLU format. Length is the number of bytes of payload encoded in VLU format. Length is the number of bytes of payload
following the Length field. The payload comprises the Type and Value following the Length field. The payload comprises the Type and Value
skipping to change at page 10, line 27 skipping to change at page 10, line 27
vlu_t type :variable*8; // "T" vlu_t type :variable*8; // "T"
uint8_t value[remainder()]; // "V" uint8_t value[remainder()]; // "V"
} payload :length*8; } payload :length*8;
} }
} :variable*8; } :variable*8;
+---/---/-------+ +---/---/-------+
| L \ T \ V | | L \ T \ V |
+---/---/-------+ +---/---/-------+
Option depiction in following figures Figure 2: Option depiction in following diagrams
2.1.4. Option List 2.1.4. Option List
An Option List is a sequence of zero or more non-empty Options An Option List is a sequence of zero or more non-empty Options
terminated by a Marker. terminated by a Marker.
+~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+-------------/-+ +~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+-------------/-+
| L \ T \ V |...............| L \ T \ V | 0 \ | | L \ T \ V |...............| L \ T \ V | 0 \ |
+~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+-------------/-+ +~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+-------------/-+
^ ^ Marker ^ ^ Marker
skipping to change at page 16, line 36 skipping to change at page 16, line 36
timestamp : If the timestampPresent flag is set, this field is timestamp : If the timestampPresent flag is set, this field is
present and contains the low 16 bits of the sender's 250 Hz clock present and contains the low 16 bits of the sender's 250 Hz clock
(4 milliseconds per tick) at transmit time. The sender's clock (4 milliseconds per tick) at transmit time. The sender's clock
MAY have its origin at any time in the past. MAY have its origin at any time in the past.
timestampEcho : If the timestampEchoPresent flag is set, this field timestampEcho : If the timestampEchoPresent flag is set, this field
is present and contains the sender's estimate of what the is present and contains the sender's estimate of what the
timestamp field of a packet received from the other end would be timestamp field of a packet received from the other end would be
at the time this packet was transmitted, using the method at the time this packet was transmitted, using the method
described in Section 3.5.2.1. described in Section 3.5.2.2.
chunks : Zero or more chunks follow the header. It is RECOMMENDED chunks : Zero or more chunks follow the header. It is RECOMMENDED
that a packet contain at least one chunk. that a packet contain at least one chunk.
padding : Zero or more bytes of padding follow the chunks. The padding : Zero or more bytes of padding follow the chunks. The
following conditions indicate padding: following conditions indicate padding:
* Fewer than three bytes (the size of a chunk header) remain in * Fewer than three bytes (the size of a chunk header) remain in
the packet. the packet.
skipping to change at page 29, line 41 skipping to change at page 29, line 41
} :chunkLength*8; } :chunkLength*8;
messageEcho : The message from the Ping to which this is a response, messageEcho : The message from the Ping to which this is a response,
unaltered. unaltered.
2.3.11. User Data Chunk 2.3.11. User Data Chunk
This chunk is the basic unit of transmission for the user messages of This chunk is the basic unit of transmission for the user messages of
a flow. A user message comprises one or more fragments. Each a flow. A user message comprises one or more fragments. Each
fragment is carried in its own chunk and has a unique sequence number fragment is carried in its own chunk and has a unique sequence number
in its flow. in its flow. It MUST ONLY be in a packet belonging to an established
session and having packet mode 1 or 2.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x10 | chunkLength | | 0x10 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|O|r| F | r |A|F| |O|r| F | r |A|F|
|P|s| R | s |B|I| |P|s| R | s |B|I|
|T|v| A | v |N|N| |T|v| A | v |N|N|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 33, line 36 skipping to change at page 33, line 36
packet. A flow sender SHOULD NOT send this option for a flow once packet. A flow sender SHOULD NOT send this option for a flow once
the flow has been acknowledged. the flow has been acknowledged.
A flow MUST NOT indicate more than one return association. A flow MUST NOT indicate more than one return association.
A flow MUST indicate its return association, if any, upon its first A flow MUST indicate its return association, if any, upon its first
transmission of a User Data chunk. A return association can't be transmission of a User Data chunk. A return association can't be
added to a sending flow after it begins. added to a sending flow after it begins.
A flow receiver MUST reject a new receiving flow having a return flow A flow receiver MUST reject a new receiving flow having a return flow
association that does not indicate an OPEN sending flow. association that does not indicate an F_OPEN sending flow.
2.3.12. Next User Data Chunk 2.3.12. Next User Data Chunk
This chunk is equivalent to the User Data Chunk for purposes of This chunk is equivalent to the User Data Chunk for purposes of
sending the user messages of a flow. When used, it MUST ONLY follow sending the user messages of a flow. When used, it MUST ONLY follow
a User Data or another Next User Data chunk in the same packet. a User Data or another Next User Data chunk in the same packet.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x11 | chunkLength | | 0x11 | chunkLength |
skipping to change at page 34, line 36 skipping to change at page 34, line 36
// 0=whole, 1=begin, 2=end, 3=middle // 0=whole, 1=begin, 2=end, 3=middle
uintn_t reserved2 :2; // "rsv" uintn_t reserved2 :2; // "rsv"
bool_t abandon :1; // "ABN" bool_t abandon :1; // "ABN"
bool_t final :1; // "FIN" bool_t final :1; // "FIN"
if(optionsPresent) if(optionsPresent)
optionList_t options :variable*8; optionList_t options :variable*8;
uint8_t userData[remainder()]; uint8_t userData[remainder()];
} :chunkLength*8; } :chunkLength*8;
This chunk is considered to be for the same flowID as the most This chunk is considered to be for the same flowID as the most
recently preceding User Data or Next User Data, having the same recently preceding User Data or Next User Data chunk in the same
Forward Sequence Number, and having the next sequence number. The packet, having the same Forward Sequence Number, and having the next
optionsPresent, fragmentControl, abandon, and final flags, and the sequence number. The optionsPresent, fragmentControl, abandon, and
options (if present) have the same interpretation as for the User final flags, and the options (if present) have the same
Data chunk. interpretation as for the User Data chunk.
... ...
----------+------------------------------------ ----------+------------------------------------
10 00 07 | User Data chunk, length=7 10 00 07 | User Data chunk, length=7
10 | OPT=0, FRA=1 "begin", ABN=0, FIN=0 10 | OPT=0, FRA=1 "begin", ABN=0, FIN=0
02 05 03 | flowID=2, seq#=5, fsn=(5-3)=2 02 05 03 | flowID=2, seq#=5, fsn=(5-3)=2
00 01 02 | data 3 bytes: 00, 01, 02 00 01 02 | data 3 bytes: 00, 01, 02
----------+------------------------------------ ----------+------------------------------------
11 00 04 | Next User Data chunk,length=4 11 00 04 | Next User Data chunk,length=4
30 | OPT=0, FRA=3 "middle", ABN=0, FIN=0 30 | OPT=0, FRA=3 "middle", ABN=0, FIN=0
| flowID=2, seq#=6, fsn=2 | flowID=2, seq#=6, fsn=2
03 04 05 | data 3 bytes: 03, 04, 05 03 04 05 | data 3 bytes: 03, 04, 05
----------+------------------------------------ ----------+------------------------------------
11 00 04 | Next User Data chunk, length=4 11 00 04 | Next User Data chunk, length=4
20 | OPT=0, FRA=2 "end", ABN=0, FIN=0 20 | OPT=0, FRA=2 "end", ABN=0, FIN=0
| flowID=2, seq#=7, fsn=2 | flowID=2, seq#=7, fsn=2
06 07 08 | data 3 bytes: 06, 07, 08 06 07 08 | data 3 bytes: 06, 07, 08
----------+------------------------------------ ----------+------------------------------------
Complete Fragmented Message: flowID=2, seq#=5, #frags=3, data (9 flowID=2, seq#=5, #frags=3, data: 00 01 02 03 04 05 06 07 08
bytes): 00 01 02 03 04 05 06 07 08
Figure 3: A fragmented message in one packet
The use of Next User Data is detailed in Section 3.6.2.3.2. The use of Next User Data is detailed in Section 3.6.2.3.2.
2.3.13. Data Acknowledgement Bitmap Chunk (Bitmap Ack) 2.3.13. Data Acknowledgement Bitmap Chunk (Bitmap Ack)
This chunk is sent by the flow receiver to indicate to the flow This chunk is sent by the flow receiver to indicate to the flow
sender the User Data sequence numbers that have been received for one sender the User Data sequence numbers that have been received for one
flow. It MUST ONLY be in a packet belonging to an established flow. It MUST ONLY be in a packet belonging to an established
session and having packet mode 1 or 2. session and having packet mode 1 or 2.
skipping to change at page 37, line 13 skipping to change at page 37, line 13
receipt of a sequence number. A clear bit indicates that sequence receipt of a sequence number. A clear bit indicates that sequence
number was not received. The least significant bit of the first number was not received. The least significant bit of the first
byte is the second sequence number following the cumulative byte is the second sequence number following the cumulative
acknowledgement, the next bit is the third sequence number acknowledgement, the next bit is the third sequence number
following, and so on. following, and so on.
50 00 05 | Bitmap Ack, length=5 bytes 50 00 05 | Bitmap Ack, length=5 bytes
05 7f 10 | flowID=5, bufAvail=127*1024 bytes, cumAck=0..16 05 7f 10 | flowID=5, bufAvail=127*1024 bytes, cumAck=0..16
79 06 | 01111001 00000110 = 18, 21, 22, 23, 24, 27, 28 79 06 | 01111001 00000110 = 18, 21, 22, 23, 24, 27, 28
Example bitmap ack indicating acknowledgement of sequence numbers 0 Figure 4: Example bitmap ack indicating acknowledgement of sequence
through 16, 18, 21 through 24, 27 and 28. numbers 0 through 16, 18, 21 through 24, 27 and 28.
2.3.14. Data Acknowledgement Ranges Chunk (Range Ack) 2.3.14. Data Acknowledgement Ranges Chunk (Range Ack)
This chunk is sent by the flow receiver to indicate to the flow This chunk is sent by the flow receiver to indicate to the flow
sender the User Data sequence numbers that have been received for one sender the User Data sequence numbers that have been received for one
flow. It MUST ONLY be in a packet belonging to an established flow. It MUST ONLY be in a packet belonging to an established
session and having packet mode 1 or 2. session and having packet mode 1 or 2.
The flow receiver can choose to acknowledge User Data with this chunk The flow receiver can choose to acknowledge User Data with this chunk
or with a Bitmap Ack. It SHOULD choose whichever format has the most or with a Bitmap Ack. It SHOULD choose whichever format has the most
skipping to change at page 39, line 16 skipping to change at page 39, line 16
ranges, run-length encoded. Runs are encoded as zero or more ranges, run-length encoded. Runs are encoded as zero or more
pairs of VLUs indicating the number (minus one) of missing pairs of VLUs indicating the number (minus one) of missing
sequence numbers followed by the number (minus one) of received sequence numbers followed by the number (minus one) of received
sequence numbers, starting at the cumulative acknowledgement. sequence numbers, starting at the cumulative acknowledgement.
51 00 07 | Range Ack, length=7 51 00 07 | Range Ack, length=7
05 7f 10 | flowID=5, bufAvail=127*1024 bytes, cumAck=0..16 05 7f 10 | flowID=5, bufAvail=127*1024 bytes, cumAck=0..16
00 00 | holes=1, received=1 -- missing 17, received 18 00 00 | holes=1, received=1 -- missing 17, received 18
01 03 | holes=2, received=4 -- missing 19..20, received 21..24 01 03 | holes=2, received=4 -- missing 19..20, received 21..24
Example range ack indicating acknowledgement of sequence numbers 0 Figure 5: Example range ack indicating acknowledgement of sequence
through 16, 18, 21, 22, 23, 24. numbers 0 through 16, 18, 21, 22, 23, 24.
2.3.15. Buffer Probe Chunk 2.3.15. Buffer Probe Chunk
This chunk is sent by the flow sender in order to request the current This chunk is sent by the flow sender in order to request the current
available receive buffer (in the form of a Data Acknowledgement) for available receive buffer (in the form of a Data Acknowledgement) for
a flow. It MUST ONLY be in a packet belonging to an established a flow. It MUST ONLY be in a packet belonging to an established
session and having packet mode 1 or 2. session and having packet mode 1 or 2.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 41, line 19 skipping to change at page 41, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This chunk has no payload. This chunk has no payload.
The use of Close Ack is detailed in Section 3.5.5. The use of Close Ack is detailed in Section 3.5.5.
3. Operation 3. Operation
3.1. Overview 3.1. Overview
+--------+ +--------+
| Peer A | S E S S I O N | Peer B |
| /=============================\ |
| || Flows || |
| ||---------------------------->|| |
| ||---------------------------->|| |
| ||<----------------------------|| |
| ||<----------------------------|| |
| ||<----------------------------|| |
| \=============================/ |
| | | |
| | +--------+
| |
| | +--------+
| | S E S S I O N | Peer C |
| /=============================\ |
| || Flows || |
| ||---------------------------->|| |
| ||<----------------------------|| |
| ||<----------------------------|| |
| \=============================/ |
| | | |
+--------+ +--------+
Figure 6: Sessions between pairs of communicating endpoints
Between any pair of communicating endpoints is a single, Between any pair of communicating endpoints is a single,
bidirectional, secured, congestion controlled session. bidirectional, secured, congestion controlled session.
Unidirectional flows convey messages from one end to the other within Unidirectional flows convey messages from one end to the other within
the session. the session.
An endpoint initiates a session to a far end when communication is An endpoint initiates a session to a far end when communication is
desired. An initiator begins with one or more candidate destination desired. An initiator begins with one or more candidate destination
socket addresses, and may learn and try more candidate addresses socket addresses, and may learn and try more candidate addresses
during startup handshaking. Eventually a first suitable response is during startup handshaking. Eventually a first suitable response is
received, and that endpoint is selected. Startup proceeds to the received, and that endpoint is selected. Startup proceeds to the
skipping to change at page 46, line 18 skipping to change at page 46, line 49
o DESTADDR: the socket address to which to send packets to the far o DESTADDR: the socket address to which to send packets to the far
end; end;
o The set of all sending flow contexts (Section 3.6.2); o The set of all sending flow contexts (Section 3.6.2);
o The set of all receiving flow contexts (Section 3.6.3); o The set of all receiving flow contexts (Section 3.6.3);
o The transmission budget, which controls the rate at which data is o The transmission budget, which controls the rate at which data is
sent into the network (for example, a congestion window); sent into the network (for example, a congestion window);
o OUTSTANDING_BYTES: the total amount of user message data o S_OUTSTANDING_BYTES: the total amount of user message data
outstanding, or in flight, in the network; that is the sum of the outstanding, or in flight, in the network; that is the sum of the
OUTSTANDING_BYTES of each sending flow in the session; F_OUTSTANDING_BYTES of each sending flow in the session;
o RX_DATA_PACKETS: a count of the number of received packets o RX_DATA_PACKETS: a count of the number of received packets
containing at least one User Data chunk since the last containing at least one User Data chunk since the last
acknowledgement was sent, initially 0; acknowledgement was sent, initially 0;
o ACK_NOW: a boolean flag indicating whether an acknowledgement o ACK_NOW: a boolean flag indicating whether an acknowledgement
should be sent immediately, initially false; should be sent immediately, initially false;
o DELACK_ALARM: an alarm to trigger an acknowledgement after a o DELACK_ALARM: an alarm to trigger an acknowledgement after a
delay, initially unset; delay, initially unset;
o The state, at any time being one of the following values: the o The state, at any time being one of the following values: the
opening states IHELLO_SENT and KEYING_SENT; the OPEN state; the opening states S_IHELLO_SENT and S_KEYING_SENT; the open state
closing states NEARCLOSE and FARCLOSE_LINGER; and the closed S_OPEN; the closing states S_NEARCLOSE and S_FARCLOSE_LINGER; and
states CLOSED and OPEN_FAILED; and the closed states S_CLOSED and S_OPEN_FAILED; and
o The role of this end of the session, which is either Initiator or o The role of this end of the session, which is either Initiator or
Responder. Responder.
3.5.1. Startup 3.5.1. Startup
3.5.1.1. Normal Handshake 3.5.1.1. Normal Handshake
RTMFP sessions are established with a 4-way handshake in two round RTMFP sessions are established with a 4-way handshake in two round
trips. The Initiator begins by sending an IHello to one or more trips. The Initiator begins by sending an IHello to one or more
candidate addresses for the desired destination endpoint. A candidate addresses for the desired destination endpoint. A
Responder statelessly sends an RHello in response. The first correct Responder statelessly sends an RHello in response. The first correct
RHello received at the Initiator is selected; all others are ignored. RHello received at the Initiator is selected; all others are ignored.
The Initiator computes its half of the session keying and sends an The Initiator computes its half of the session keying and sends an
IIKeying. The Responder receives the IIKeying, and if it is IIKeying. The Responder receives the IIKeying, and if it is
acceptable, computes its half of the session keying, at which point acceptable, computes its half of the session keying, at which point
it can also compute the shared session keying and session nonces. it can also compute the shared session keying and session nonces.
The Responder creates a new S_OPEN session with the Initiator, and
The Responder creates a new OPEN session with the Initiator, and
sends an RIKeying. The Initiator receives the RIKeying, and if it is sends an RIKeying. The Initiator receives the RIKeying, and if it is
acceptable, it computes the shared session keying and session nonces. acceptable, it computes the shared session keying and session nonces.
The Initiator's session is now OPEN. The Initiator's session is now S_OPEN.
. Initiator Responder . . Initiator Responder .
| IHello | | IHello |
|(EPD,Tag) | |(EPD,Tag) |
IHELLO_SENT |(SID=0) | S_IHELLO_SENT |(SID=0) |
|------------------------------->| |------------------------------->|
| | | |
| RHello | | RHello |
| (Tag,Cookie,RCert)| | (Tag,Cookie,RCert)|
| (SID=0)| | (SID=0)|
|<-------------------------------| |<-------------------------------|
KEYING_SENT | | S_KEYING_SENT | |
| IIKeying | | IIKeying |
|(ISID,Cookie,ICert,SKIC,ISig) | |(ISID,Cookie,ICert,SKIC,ISig) |
|(SID=0) | |(SID=0) |
|------------------------------->| |------------------------------->|
| | | |
| RIKeying | | RIKeying |
| (RSID,SKRC,RSig)| | (RSID,SKRC,RSig)|
| (SID=ISID,Key=Default)| OPEN | (SID=ISID,Key=Default)| S_OPEN
|<-------------------------------| |<-------------------------------|
OPEN | | S_OPEN | |
| S E S S I O N | | S E S S I O N |
|<-------------------(SID=ISID)--| |<-------------------(SID=ISID)--|
. |--(SID=RSID)------------------->| . |--(SID=RSID)------------------->|
Normal Handshake. Figure 7: Normal handshake
In the following sections the handshake is detailed from the In the following sections the handshake is detailed from the
perspectives of the Initiator and Responder. perspectives of the Initiator and Responder.
3.5.1.1.1. Initiator 3.5.1.1.1. Initiator
The Initiator determines that a session is needed for an Endpoint The Initiator determines that a session is needed for an Endpoint
Discriminator. The Initiator creates state for a new opening session Discriminator. The Initiator creates state for a new opening session
and begins with a candidate endpoint address set containing at least and begins with a candidate endpoint address set containing at least
one address. The new session is placed in the IHELLO_SENT state. one address. The new session is placed in the S_IHELLO_SENT state.
If the session does not move to the OPEN state before an ultimate If the session does not move to the S_OPEN state before an ultimate
open timeout, the session has failed and moves to the OPEN_FAILED open timeout, the session has failed and moves to the S_OPEN_FAILED
state. The RECOMMENDED ultimate open timeout is 95 seconds. state. The RECOMMENDED ultimate open timeout is 95 seconds.
The Initiator chooses a new, unique Tag not used by any currently The Initiator chooses a new, unique Tag not used by any currently
opening session. The Tag SHOULD be cryptographically pseudorandom opening session. The Tag SHOULD be cryptographically pseudorandom
and SHOULD NOT be less than 8 bytes in length. The Initiator and SHOULD NOT be less than 8 bytes in length. The Initiator
constructs an IHello chunk (Section 2.3.2) with the Endpoint constructs an IHello chunk (Section 2.3.2) with the Endpoint
Discriminator and the Tag. Discriminator and the Tag.
While the Initiator is in the IHELLO_SENT state, it sends the IHello While the Initiator is in the S_IHELLO_SENT state, it sends the
to each candidate endpoint address in the set, on a backoff schedule. IHello to each candidate endpoint address in the set, on a backoff
The backoff SHOULD NOT be less than multiplicative with not less than schedule. The backoff SHOULD NOT be less than multiplicative with
1.5 seconds added to the interval between each attempt. The backoff not less than 1.5 seconds added to the interval between each attempt.
SHOULD be scheduled separately for each candidate address, since new The backoff SHOULD be scheduled separately for each candidate
candidates can be added over time. address, since new candidates can be added over time.
If the Initiator receives a Redirect chunk (Section 2.3.5) with a Tag If the Initiator receives a Redirect chunk (Section 2.3.5) with a Tag
Echo matching this session, AND this session is in the IHELLO_SENT Echo matching this session, AND this session is in the S_IHELLO_SENT
state, then for each redirect destination indicated in the Redirect: state, then for each redirect destination indicated in the Redirect:
if the candidate endpoint address set contains fewer than if the candidate endpoint address set contains fewer than
REDIRECT_THRESHOLD addresses, add the indicated redirect destination REDIRECT_THRESHOLD addresses, add the indicated redirect destination
to the candidate endpoint address set. REDIRECT_THRESHOLD SHOULD NOT to the candidate endpoint address set. REDIRECT_THRESHOLD SHOULD NOT
be more than 24. be more than 24.
If the Initiator receives an RHello chunk (Section 2.3.4) with a Tag If the Initiator receives an RHello chunk (Section 2.3.4) with a Tag
Echo matching this session, AND this session is in the IHELLO_SENT Echo matching this session, AND this session is in the S_IHELLO_SENT
state, AND the Responder certificate matches the desired Endpoint state, AND the Responder certificate matches the desired Endpoint
Discriminator, AND the certificate is authentic according to the Discriminator, AND the certificate is authentic according to the
Cryptography Profile, then: Cryptography Profile, then:
1. If the Canonical Endpoint Discriminator for the responder 1. If the Canonical Endpoint Discriminator for the responder
certificate matches the Canonical Endpoint Discriminator of certificate matches the Canonical Endpoint Discriminator of
another existing session in the KEYING_SENT or OPEN states, AND another existing session in the S_KEYING_SENT or S_OPEN states,
the certificate of the other opening session matches the desired AND the certificate of the other opening session matches the
Endpoint Discriminator, then: this session is a duplicate and desired Endpoint Discriminator, then: this session is a duplicate
SHOULD be aborted in favor of the other existing session; and SHOULD be aborted in favor of the other existing session;
otherwise otherwise
2. Move to the KEYING_SENT state. Set DESTADDR, the far end address 2. Move to the S_KEYING_SENT state. Set DESTADDR, the far end
for the session, to the address from which this RHello was address for the session, to the address from which this RHello
received. The Initiator chooses a new, unique receive session was received. The Initiator chooses a new, unique receive
ID, not used by any other session, for the Responder to use when session ID, not used by any other session, for the Responder to
sending packets to the Initiator. It computes a Session Key use when sending packets to the Initiator. It computes a Session
Initiator Component appropriate to the responder's certificate Key Initiator Component appropriate to the responder's
according to the Cryptography Profile. Using this data and the certificate according to the Cryptography Profile. Using this
cookie from the RHello, the Initiator constructs and signs an data and the cookie from the RHello, the Initiator constructs and
IIKeying chunk (Section 2.3.7). signs an IIKeying chunk (Section 2.3.7).
While the Initiator is in the KEYING_SENT state, it sends the While the Initiator is in the S_KEYING_SENT state, it sends the
IIKeying to DESTADDR on a backoff schedule. The backoff SHOULD NOT IIKeying to DESTADDR on a backoff schedule. The backoff SHOULD NOT
be less than multiplicative with not less than 1.5 seconds added to be less than multiplicative with not less than 1.5 seconds added to
the interval between each attempt. the interval between each attempt.
If the Initiator receives an RIKeying chunk (Section 2.3.8) in a If the Initiator receives an RIKeying chunk (Section 2.3.8) in a
packet with this session's receive session identifier, AND this packet with this session's receive session identifier, AND this
session is in the KEYING_SENT state, AND the signature in the chunk session is in the S_KEYING_SENT state, AND the signature in the chunk
is authentic according to the far end's certificate (from the is authentic according to the far end's certificate (from the
RHello), AND the Session Key Responder Component successfully RHello), AND the Session Key Responder Component successfully
combines with the Session Key Initiator Component and the near and combines with the Session Key Initiator Component and the near and
far certificates to form the shared session keys and nonces according far certificates to form the shared session keys and nonces according
to the Cryptography Profile, then the session has opened to the Cryptography Profile, then the session has opened
successfully. The session moves to the OPEN state. The send session successfully. The session moves to the S_OPEN state. The send
identifier is set from the RIKeying. Packet encryption, decryption, session identifier is set from the RIKeying. Packet encryption,
and verification now use the newly computed shared session keys, and decryption, and verification now use the newly computed shared
the session nonces are available for application-layer cryptographic session keys, and the session nonces are available for application-
challenges. layer cryptographic challenges.
3.5.1.1.2. Responder 3.5.1.1.2. Responder
On receipt of an IHello chunk (Section 2.3.2) with an Endpoint On receipt of an IHello chunk (Section 2.3.2) with an Endpoint
Discriminator that selects its identity, an endpoint SHOULD construct Discriminator that selects its identity, an endpoint SHOULD construct
an RHello chunk (Section 2.3.4) and send it to the address from which an RHello chunk (Section 2.3.4) and send it to the address from which
the IHello was received. To avoid a potential resource exhaustion the IHello was received. To avoid a potential resource exhaustion
denial-of-service, the endpoint SHOULD NOT create any persistent denial-of-service, the endpoint SHOULD NOT create any persistent
state associated with the IHello. The endpoint MUST generate the state associated with the IHello. The endpoint MUST generate the
cookie for the RHello in such a way that it can be recognized as cookie for the RHello in such a way that it can be recognized as
authentic and valid when echoed in an IIKeying. The endpoint SHOULD authentic and valid when echoed in an IIKeying. The endpoint SHOULD
use the address from which the IHello was received as part of the use the address from which the IHello was received as part of the
cookie generation formula. Cookies SHOULD be valid only for a cookie generation formula. Cookies SHOULD be valid only for a
limited time; that lifetime SHOULD NOT be less than 95 seconds. limited time; that lifetime SHOULD NOT be less than 95 seconds (the
recommended ultimate session open timeout).
On receipt of an FIHello chunk (Section 2.3.3) from a Forwarder On receipt of an FIHello chunk (Section 2.3.3) from a Forwarder
(Section 3.5.1.5) where the Endpoint Discriminator selects its (Section 3.5.1.5) where the Endpoint Discriminator selects its
identity, an endpoint SHOULD do one of the following: identity, an endpoint SHOULD do one of the following:
1. Compute, construct and send an RHello as though the FIHello was 1. Compute, construct and send an RHello as though the FIHello was
an IHello received from the indicated reply address; or an IHello received from the indicated reply address; or
2. Construct and send an Implied Redirect (Section 2.3.5) to the 2. Construct and send an Implied Redirect (Section 2.3.5) to the
FIHello's reply address; or FIHello's reply address; or
skipping to change at page 50, line 4 skipping to change at page 50, line 47
3. Ignore this FIHello. 3. Ignore this FIHello.
On receipt of an IIKeying chunk (Section 2.3.7), if the cookie is not On receipt of an IIKeying chunk (Section 2.3.7), if the cookie is not
authentic or if it has expired, ignore this IIKeying; otherwise, authentic or if it has expired, ignore this IIKeying; otherwise,
On receipt of an IIKeying chunk, if the cookie appears authentic but On receipt of an IIKeying chunk, if the cookie appears authentic but
does not match the address from which the IIKeying's packet was does not match the address from which the IIKeying's packet was
received, perform the special processing at Cookie Change received, perform the special processing at Cookie Change
(Section 3.5.1.2); otherwise, (Section 3.5.1.2); otherwise,
On receipt of an IIKeying with an authentic and valid cookie, if the On receipt of an IIKeying with an authentic and valid cookie, if the
certificate is authentic according to the Cryptography Profile, AND certificate is authentic according to the Cryptography Profile, AND
the signature in the chunk is authentic according to the far end's the signature in the chunk is authentic according to the far end's
certificate and the Cryptography Profile, AND the Session Key certificate and the Cryptography Profile, AND the Session Key
Initiator Component is acceptable, then: Initiator Component is acceptable, then:
1. If the address from which this IIKeying was received corresponds 1. If the address from which this IIKeying was received corresponds
to an opening session in the IHELLO_SENT or KEYING_SENT state, to an opening session in the S_IHELLO_SENT or S_KEYING_SENT
perform the special processing at Glare (Section 3.5.1.3); state, perform the special processing at Glare (Section 3.5.1.3);
otherwise, otherwise,
2. If the address from which this IIKeying was received corresponds 2. If the address from which this IIKeying was received corresponds
to a session in the OPEN state, then: to a session in the S_OPEN state, then:
1. If the receiver was the Responder for the OPEN session and 1. If the receiver was the Responder for the S_OPEN session and
the session identifier, certificate, and Session Key the session identifier, certificate, and Session Key
Initiator Component are identical to those of the OPEN Initiator Component are identical to those of the S_OPEN
session, this IIKeying is a retransmission, so resend the session, this IIKeying is a retransmission, so resend the
OPEN session's RIKeying using the Default Session Key as S_OPEN session's RIKeying using the Default Session Key as
specified below; otherwise, specified below; otherwise,
2. If the certificate from this IIKeying does not override the 2. If the certificate from this IIKeying does not override the
certificate of the OPEN session: ignore this IIKeying; certificate of the S_OPEN session: ignore this IIKeying;
otherwise, otherwise,
3. The certificate from this IIKeying overrides the certificate 3. The certificate from this IIKeying overrides the certificate
of the OPEN session; this is a new opening session from the of the S_OPEN session; this is a new opening session from the
same identity and the existing OPEN session is stale. Move same identity and the existing S_OPEN session is stale. Move
the existing OPEN session to CLOSED and abort all of its the existing S_OPEN session to S_CLOSED and abort all of its
flows (signaling exceptions to the user), then continue flows (signaling exceptions to the user), then continue
processing this IIKeying. processing this IIKeying.
Otherwise, Otherwise,
3. Compute a Session Key Responder Component and choose a new, 3. Compute a Session Key Responder Component and choose a new,
unique receive session ID not used by any other session for the unique receive session ID not used by any other session for the
Initiator to use when sending packets to the Responder. Using Initiator to use when sending packets to the Responder. Using
this data, construct and, with the Session Key Initiator this data, construct and, with the Session Key Initiator
Component, sign an RIKeying chunk (Section 2.3.8). Using the Component, sign an RIKeying chunk (Section 2.3.8). Using the
Session Key Initiator and Responder Components and the near and Session Key Initiator and Responder Components and the near and
far certificates, the Responder combines and computes the shared far certificates, the Responder combines and computes the shared
session keys and nonces according to the Cryptography Profile. session keys and nonces according to the Cryptography Profile.
The Responder creates a new session in the OPEN state, with the The Responder creates a new session in the S_OPEN state, with the
far endpoint address DESTADDR taken from the source address of far endpoint address DESTADDR taken from the source address of
the packet containing the IIKeying and the send session the packet containing the IIKeying and the send session
identifier taken from the IIKeying. The Responder sends the identifier taken from the IIKeying. The Responder sends the
RIKeying to the Initiator using the Default Session Key and the RIKeying to the Initiator using the Default Session Key and the
requested send session identifier. Packet encryption, requested send session identifier. Packet encryption,
decryption, and verification of all future packets for this decryption, and verification of all future packets for this
session use the newly computed keys, and the session nonces are session use the newly computed keys, and the session nonces are
available for application-layer cryptographic challenges. available for application-layer cryptographic challenges.
3.5.1.2. Cookie Change 3.5.1.2. Cookie Change
skipping to change at page 51, line 46 skipping to change at page 52, line 43
If Responder determines that it generated the cookie in the IIKeying If Responder determines that it generated the cookie in the IIKeying
but the cookie doesn't match the sender's address (for example, if but the cookie doesn't match the sender's address (for example, if
the cookie is in two parts, with a first part generated independently the cookie is in two parts, with a first part generated independently
of the Initiator's address, and a second part dependent on the of the Initiator's address, and a second part dependent on the
address), Responder SHOULD generate a new cookie based on the address address), Responder SHOULD generate a new cookie based on the address
from which the IIKeying was received, and send an RHello Cookie from which the IIKeying was received, and send an RHello Cookie
Change chunk (Section 2.3.6) to the source of the IIKeying, using the Change chunk (Section 2.3.6) to the source of the IIKeying, using the
session ID from the IIKeying and the Default Session Key. session ID from the IIKeying and the Default Session Key.
If Initiator receives an RHello Cookie Change chunk for a session in If Initiator receives an RHello Cookie Change chunk for a session in
the KEYING_SENT state, AND the old cookie matches the one originally the S_KEYING_SENT state, AND the old cookie matches the one
sent to the Responder, then: Initiator adopts the new cookie, originally sent to the Responder, then: Initiator adopts the new
constructs and signs a new IIKeying chunk, and sends the new IIKeying cookie, constructs and signs a new IIKeying chunk, and sends the new
to the Responder. Initiator SHOULD NOT change the cookie for a IIKeying to the Responder. Initiator SHOULD NOT change the cookie
session more than once. for a session more than once.
Initiator Forwarder Responder Initiator Forwarder Responder
| IHello | | | IHello | |
|(Src=Ix) | | |(Src=Ix) | |
|------------------------------->| | |------------------------------->| |
| | FIHello | | | FIHello |
| |(RA=Ix) | | |(RA=Ix) |
| |-------------------------------->| | |-------------------------------->|
| | | |
| RHello | | RHello |
skipping to change at page 52, line 34 skipping to change at page 53, line 34
| | | |
| IIKeying | | IIKeying |
|(Cookie:Iy) | |(Cookie:Iy) |
|----------------------------------------------------------------->| |----------------------------------------------------------------->|
| | | |
| RIKeying | | RIKeying |
|<-----------------------------------------------------------------| |<-----------------------------------------------------------------|
| | | |
|<======================== S E S S I O N =========================>| |<======================== S E S S I O N =========================>|
Handshake with Cookie Change. Figure 8: Handshake with Cookie Change
3.5.1.3. Glare 3.5.1.3. Glare
Glare occurs when two endpoints attempt to initiate sessions to each Glare occurs when two endpoints attempt to initiate sessions to each
other concurrently. Glare is detected by receipt of a valid and other concurrently. Glare is detected by receipt of a valid and
authentic IIKeying from an endpoint address which is a destination authentic IIKeying from an endpoint address which is a destination
for an opening session. Only one session is allowed between a pair for an opening session. Only one session is allowed between a pair
of endpoints. of endpoints.
Glare is resolved by comparing the certificate in the received Glare is resolved by comparing the certificate in the received
skipping to change at page 53, line 17 skipping to change at page 54, line 17
1. If the certificate in the IIKeying overrides the certificate 1. If the certificate in the IIKeying overrides the certificate
associated with the near opening session according to the associated with the near opening session according to the
Cryptography Profile, then: abort and destroy the near opening Cryptography Profile, then: abort and destroy the near opening
session. Then, session. Then,
2. Continue with normal Responder IIKeying processing 2. Continue with normal Responder IIKeying processing
(Section 3.5.1.1.2). (Section 3.5.1.1.2).
3.5.1.4. Redirector 3.5.1.4. Redirector
+-----------+ +------------+ +-----------+
| Initiator |---------->| Redirector | | Responder |
| |<----------| | | |
| | +------------+ | |
| |<=================================>| |
+-----------+ +-----------+
Figure 9: Redirector
A Redirector acts like a name server for Endpoint Discriminators. An A Redirector acts like a name server for Endpoint Discriminators. An
Initiator MAY use a Redirector to discover additional candidate Initiator MAY use a Redirector to discover additional candidate
endpoint addresses for a desired endpoint. endpoint addresses for a desired endpoint.
On receipt of an IHello chunk with an Endpoint Discriminator that On receipt of an IHello chunk with an Endpoint Discriminator that
does not select the Redirector's identity, the Redirector constructs does not select the Redirector's identity, the Redirector constructs
and sends a Responder Redirect chunk (Section 2.3.5) back to the and sends a Responder Redirect chunk (Section 2.3.5) back to the
Initiator containing one or more additional candidate addresses for Initiator containing one or more additional candidate addresses for
the indicated endpoint. the indicated endpoint.
skipping to change at page 53, line 48 skipping to change at page 55, line 26
|<-----------------------------------------------------------------| |<-----------------------------------------------------------------|
| | | |
| IIKeying | | IIKeying |
|----------------------------------------------------------------->| |----------------------------------------------------------------->|
| | | |
| RIKeying | | RIKeying |
|<-----------------------------------------------------------------| |<-----------------------------------------------------------------|
| | | |
|<======================== S E S S I O N =========================>| |<======================== S E S S I O N =========================>|
Handshake using a Redirector. Figure 10: Handshake using a Redirector
Redirectors SHOULD NOT initiate new sessions to endpoints which might Redirectors SHOULD NOT initiate new sessions to endpoints which might
use the Redirector's address as a candidate for another endpoint, use the Redirector's address as a candidate for another endpoint,
since the far end might interpret the Redirector's IIKeying as glare since the far end might interpret the Redirector's IIKeying as glare
for the far end's initiation to the other endpoint. for the far end's initiation to the other endpoint.
3.5.1.5. Forwarder 3.5.1.5. Forwarder
+-----------+ +-----------+ +---+ +-----------+
| Initiator |---->| Forwarder |<===>| N |<===>| Responder |
| | +-----------+ | A | | |
| |<=====================>| T |<===>| |
+-----------+ +---+ +-----------+
Figure 11: Forwarder
A Responder might be behind a NAT or firewall that doesn't allow A Responder might be behind a NAT or firewall that doesn't allow
inbound packets to reach the endpoint until it first sends an inbound packets to reach the endpoint until it first sends an
outbound packet for a particular far endpoint address. outbound packet for a particular far endpoint address.
A Forwarder's endpoint address MAY be a candidate address for another A Forwarder's endpoint address MAY be a candidate address for another
endpoint. A Responder MAY use a Forwarder to receive FIHello chunks endpoint. A Responder MAY use a Forwarder to receive FIHello chunks
sent on behalf of an Initiator. sent on behalf of an Initiator.
On receipt of an IHello chunk with an Endpoint Discriminator that On receipt of an IHello chunk with an Endpoint Discriminator that
does not select the Forwarder's identity, if the Forwarder has an does not select the Forwarder's identity, if the Forwarder has an
OPEN session with an endpoint whose certificate matches the desired S_OPEN session with an endpoint whose certificate matches the desired
Endpoint Discriminator, the forwarder constructs and sends an FIHello Endpoint Discriminator, the forwarder constructs and sends an FIHello
chunk (Section 2.3.3) to the selected endpoint over the OPEN session, chunk (Section 2.3.3) to the selected endpoint over the S_OPEN
using the Tag and Endpoint Discriminator from the IHello chunk and session, using the Tag and Endpoint Discriminator from the IHello
the source address of the packet containing the IHello for the chunk and the source address of the packet containing the IHello for
corresponding fields of the FIHello. the corresponding fields of the FIHello.
On receipt of an FIHello chunk, a Responder might send an RHello or On receipt of an FIHello chunk, a Responder might send an RHello or
Implied Redirect to the original source of the IHello Implied Redirect to the original source of the IHello
(Section 3.5.1.1.2), potentially allowing future packets to flow (Section 3.5.1.1.2), potentially allowing future packets to flow
directly between the Initiator and Responder through the NAT or directly between the Initiator and Responder through the NAT or
firewall. firewall.
Initiator Forwarder NAT Responder Initiator Forwarder NAT Responder
| IHello | | | | IHello | | |
|------------------------------->| | | |------------------------------->| | |
skipping to change at page 54, line 50 skipping to change at page 56, line 36
| : | | : |
| IIKeying : | | IIKeying : |
|-------------------------------------------------:--------------->| |-------------------------------------------------:--------------->|
| : | | : |
| : RIKeying | | : RIKeying |
| :<---------------| | :<---------------|
|<------------------------------------------------: | |<------------------------------------------------: |
| : | | : |
|<======================== S E S S I O N ========>:<==============>| |<======================== S E S S I O N ========>:<==============>|
Example Forwarder handshake where Responder sends an RHello. Figure 12: Forwarder handshake where Responder sends an RHello
Initiator Forwarder NAT Responder Initiator Forwarder NAT Responder
| IHello | | | | IHello | | |
|------------------------------->| | | |------------------------------->| | |
| | FIHello | | | | FIHello | |
| |--------------->|--------------->| | |--------------->|--------------->|
| | | | | |
| | Redirect | | | Redirect |
| | (Implied,RD={})| | | (Implied,RD={})|
| :<---------------| | :<---------------|
skipping to change at page 55, line 32 skipping to change at page 57, line 32
| : | | : |
| IIKeying : | | IIKeying : |
|------------------------------------------------>:--------------->| |------------------------------------------------>:--------------->|
| : | | : |
| : RIKeying | | : RIKeying |
| :<---------------| | :<---------------|
|<------------------------------------------------: | |<------------------------------------------------: |
| : | | : |
|<======================== S E S S I O N ========>:<==============>| |<======================== S E S S I O N ========>:<==============>|
Example Forwarder handshake where Responder sends an Implied Figure 13: Forwarder handshake where Responder sends an Implied
Redirect. Redirect
3.5.1.6. Redirector and Forwarder with NAT 3.5.1.6. Redirector and Forwarder with NAT
+---+ +---+ +---+ +---+ +---+
| I | | N | | I | | N | | R |
| n |------>| A |------>| n | | A | | e |
| i | | T | | t |<====>| T |<====>| s |
| t |<------| |<------| r | | | | p |
| i | | | | o | | | | o |
| a | | | +---+ | | | n |
| t | | | | | | d |
| o |<=====>| |<================>| |<====>| e |
| r | | | | | | r |
+---+ +---+ +---+ +---+
Figure 14: Introduction service for Initiator and Responder behind
NATs
An Initiator and Responder might each be behind distinct NATs or An Initiator and Responder might each be behind distinct NATs or
firewalls that don't allow inbound packets to reach the respective firewalls that don't allow inbound packets to reach the respective
endpoints until each first sends an outbound packet for a particular endpoints until each first sends an outbound packet for a particular
far endpoint address. far endpoint address.
An introduction service comprising Redirector and Forwarder functions An introduction service comprising Redirector and Forwarder functions
may facilitate direct communication between endpoints each behind a may facilitate direct communication between endpoints each behind a
NAT. NAT.
Responder is registered with the introduction service via an OPEN Responder is registered with the introduction service via an S_OPEN
session to it. The service observes and records Responder's public session to it. The service observes and records Responder's public
NAT address as the DESTADDR of the OPEN session. The service MAY NAT address as the DESTADDR of the S_OPEN session. The service MAY
record other addresses for Responder, for example addresses Responder record other addresses for Responder, for example addresses Responder
self-reports as being directly attached. self-reports as being directly attached.
Initiator begins with an address of the introduction service as an Initiator begins with an address of the introduction service as an
initial candidate. The Redirector portion of the service sends a initial candidate. The Redirector portion of the service sends a
Responder Redirect to Initiator containing at least Responder's Responder Redirect to Initiator containing at least Responder's
public NAT address as previously recorded. The Forwarder portion of public NAT address as previously recorded. The Forwarder portion of
the service sends a Forwarded IHello to Responder containing the service sends a Forwarded IHello to Responder containing
Initiator's public NAT address as observed as the source of the Initiator's public NAT address as observed as the source of the
IHello. IHello.
skipping to change at page 57, line 41 skipping to change at page 59, line 41
| IIKeying : : | | IIKeying : : |
|-------------->: : | |-------------->: : |
| :-------------------------------->:--------------->| | :-------------------------------->:--------------->|
| : : | | : : |
| : : RIKeying | | : : RIKeying |
| : :<---------------| | : :<---------------|
|<--------------:<--------------------------------: | |<--------------:<--------------------------------: |
| : : | | : : |
|<=============>:<======== S E S S I O N ========>:<==============>| |<=============>:<======== S E S S I O N ========>:<==============>|
Figure 15: Handshake with Redirector and Forwarder
At the point in the diagram marked (*), Responder's RHello from the At the point in the diagram marked (*), Responder's RHello from the
FIHello might arrive at Initiator's NAT before or after Initiator's FIHello might arrive at Initiator's NAT before or after Initiator's
IHello is sent outbound to Responder's public NAT address. If it IHello is sent outbound to Responder's public NAT address. If it
arrives before, it may be dropped by the NAT. If it arrives after, arrives before, it may be dropped by the NAT. If it arrives after,
it will transit the NAT and trigger keying without waiting for it will transit the NAT and trigger keying without waiting for
another round trip time. The timing of this race depends, among another round trip time. The timing of this race depends, among
other factors, on the relative distances of Initiator and Responder other factors, on the relative distances of Initiator and Responder
to each other and the introduction service. to each other and the introduction service.
3.5.2. Congestion Control 3.5.2. Congestion Control
An RTMFP MUST implement congestion control and avoidance algorithms An RTMFP MUST implement congestion control and avoidance algorithms
that are "TCP compatible", in accordance with Internet best current that are "TCP compatible", in accordance with Internet best current
practice [RFC2914]. The algorithms SHOULD NOT be more aggressive practice [RFC2914]. The algorithms SHOULD NOT be more aggressive
than those described in TCP Congestion Control [RFC5681]. than those described in TCP Congestion Control [RFC5681], and MUST
NOT be more aggressive than the "slow start algorithm" described in
RFC 5681 Section 3.1.
An endpoint maintains a transmission budget in the session An endpoint maintains a transmission budget in the session
information context of each OPEN session, controlling the rate at information context of each S_OPEN session (Section 3.5), controlling
which the endpoint sends data into the network. For window-based the rate at which the endpoint sends data into the network.
congestion control and avoidance algorithms, the transmission budget
is the congestion window, which is the amount of user data that is
allowed to be outstanding, or in flight, in the network. An endpoint
increases and decreases the transmission budget in response to
acknowledgements and timeouts according to the congestion control and
avoidance algorithms.
A sender MAY implement "slow start" as specified in RFC 5681. For window-based congestion control and avoidance algorithms, the
However, a sender MUST disable "slow start", and behave as though transmission budget is the congestion window, which is the amount of
ssthresh is clamped to 0, on a session where a Time Critical Reverse user data that is allowed to be outstanding, or in flight, in the
Notification (Section 2.2.4) indication has been received from the network. Transmission is allowed when S_OUTSTANDING_BYTES
far end within the last at least 800 milliseconds, unless the sender (Section 3.5) is less than the congestion window (Section 3.6.2.3).
is itself sending time critical data to the far end.
A sender SHOULD NOT increase the transmission budget by more than 384 An endpoint avoids sending large bursts of data or packets into the
bytes per round trip or 0.5% (whichever is greater) each round trip network (Section 3.5.2.3).
on a session where a Time Critical Reverse Notification indication
has been received from the far end within the last at least 800
milliseconds, unless the sender is itself sending time critical data
to the far end.
3.5.2.1. Retransmission Timeout A sending endpoint increases and decreases its transmission budget in
response to acknowledgements (Section 3.6.2.4) and loss according to
the congestion control and avoidance algorithms. Loss is detected by
negative acknowledgement (Section 3.6.2.5) and timeout
(Section 3.6.2.6).
Timeout is determined by the Effective Retransmission Timeout ERTO
(Section 3.5.2.2). ERTO is measured using the Timestamp and
Timestamp Echo packet header fields (Section 2.2.4).
A receiving endpoint acknowledges all received data (Section 3.6.3.4)
to enable the sender to measure receipt of data, or lack thereof.
A receiving endpoint may be receiving time critical (or real-time)
data from a first sender while receiving data from other senders.
The receiving endpoint can signal its other senders (Section 2.2.4)
to cause them to decrease the aggressiveness of their congestion
control and avoidance algorithms, in order to yield network capacity
to the time critical data (Section 3.5.2.1).
3.5.2.1. Time Critical Reverse Notification
A sender can increase its transmission budget at a rate compatible
with (but not exceeding) the "slow start algorithm" specified in RFC
5681 (with which the transmission rate is doubled every round trip
when beginning or restarting transmission, until loss is detected).
However, a sender MUST behave as though the slow start threshold
SSTHRESH is clamped to 0 (disabling the slow start algorithm's
exponential increase behavior) on a session where a Time Critical
Reverse Notification (Section 2.2.4) indication has been received
from the far end within the last 800 milliseconds, unless the sender
is itself currently sending time critical data to the far end.
During each round trip, a sender SHOULD NOT increase the transmission
budget by more than 0.5% or by 384 bytes per round trip (whichever is
greater) on a session where a Time Critical Reverse Notification
indication has been received from the far end within the last 800
milliseconds, unless the sender is itself currently sending time
critical data to the far end.
3.5.2.2. Retransmission Timeout
RTMFP uses the Effective Retransmission Timeout ERTO to detect when a RTMFP uses the Effective Retransmission Timeout ERTO to detect when a
user data fragment has been lost in the network. The ERTO is user data fragment has been lost in the network. The ERTO is
typically calculated in a manner similar to that specified in typically calculated in a manner similar to that specified in
Requirements for Internet Hosts - Communication Layers [RFC1122], and Requirements for Internet Hosts - Communication Layers [RFC1122], and
is a function of round trip time measurements and persistent timeout is a function of round trip time measurements and persistent timeout
behavior. behavior.
The ERTO SHOULD be at least 250 milliseconds and SHOULD allow for the The ERTO SHOULD be at least 250 milliseconds and SHOULD allow for the
receiver to delay sending an acknowledgement for up to 200 receiver to delay sending an acknowledgement for up to 200
milliseconds (Section 3.6.3.4.4). The ERTO MUST NOT be less than the milliseconds (Section 3.6.3.4.4). The ERTO MUST NOT be less than the
round trip time. round trip time.
To facilitate round trip time measurement, an endpoint MUST implement To facilitate round trip time measurement, an endpoint MUST implement
the Timestamp Echo facility: the Timestamp Echo facility:
o On a session entering the OPEN state, initialize TS_RX_TIME to o On a session entering the S_OPEN state, initialize TS_RX_TIME to
negative infinity, and TS_RX and TS_ECHO_TX to have no value. negative infinity, and TS_RX and TS_ECHO_TX to have no value.
o On receipt of a packet in an OPEN session with the o On receipt of a packet in an S_OPEN session with the
timestampPresent (Section 2.2.4) flag set, if the timestamp field timestampPresent (Section 2.2.4) flag set, if the timestamp field
in the packet is different than TS_RX: set TS_RX to the value of in the packet is different than TS_RX: set TS_RX to the value of
the timestamp field in the packet, and set TS_RX_TIME to the the timestamp field in the packet, and set TS_RX_TIME to the
current time. current time.
o When sending a packet to the far end in an OPEN session: o When sending a packet to the far end in an S_OPEN session:
1. Calculate TS_RX_ELAPSED = current time - TS_RX_TIME. If 1. Calculate TS_RX_ELAPSED = current time - TS_RX_TIME. If
TS_RX_ELAPSED is more than 128 seconds, then set TS_RX and TS_RX_ELAPSED is more than 128 seconds, then set TS_RX and
TS_ECHO_TX to have no value and do not include a timestamp TS_ECHO_TX to have no value and do not include a timestamp
echo; otherwise echo; otherwise
2. Calculate TS_RX_ELAPSED_TICKS to be the number of whole 4 2. Calculate TS_RX_ELAPSED_TICKS to be the number of whole 4
millisecond periods in TS_RX_ELAPSED; then millisecond periods in TS_RX_ELAPSED; then
3. Calculate TS_ECHO = (TS_RX + TS_RX_ELAPSED_TICKS) MODULO 3. Calculate TS_ECHO = (TS_RX + TS_RX_ELAPSED_TICKS) MODULO
skipping to change at page 60, line 5 skipping to change at page 62, line 38
initialized to have no value; initialized to have no value;
o SRTT: the smoothed round-trip time, initialized to have no value; o SRTT: the smoothed round-trip time, initialized to have no value;
o RTTVAR: the round-trip time variance, initialized to 0; o RTTVAR: the round-trip time variance, initialized to 0;
Initialize MRTO to 250 milliseconds. Initialize MRTO to 250 milliseconds.
Initialize ERTO to 3 seconds. Initialize ERTO to 3 seconds.
On sending a packet to the far end of an OPEN session, if the current On sending a packet to the far end of an S_OPEN session, if the
send timestamp is not equal to TS_TX, then: set TS_TX to the current current send timestamp is not equal to TS_TX, then: set TS_TX to the
send timestamp, set the timestampPresent flag in the packet header, current send timestamp, set the timestampPresent flag in the packet
and set the timestamp field to TS_TX. header, and set the timestamp field to TS_TX.
On receipt of a packet from the far end of an OPEN session, if the On receipt of a packet from the far end of an S_OPEN session, if the
timestampEchoPresent flag is set in the packet header AND the timestampEchoPresent flag is set in the packet header AND the
timestampEcho field is not equal to TS_ECHO_RX, then: timestampEcho field is not equal to TS_ECHO_RX, then:
1. Set TS_ECHO_RX to timestampEcho; 1. Set TS_ECHO_RX to timestampEcho;
2. Calculate RTT_TICKS = (current send timestamp - timestampEcho) 2. Calculate RTT_TICKS = (current send timestamp - timestampEcho)
MODULO 65536; MODULO 65536;
3. If RTT_TICKS is greater than 32767, the measurement is invalid, 3. If RTT_TICKS is greater than 32767, the measurement is invalid,
so discard this measurement; otherwise so discard this measurement; otherwise
skipping to change at page 60, line 42 skipping to change at page 63, line 28
6. If SRTT has no value, then set SRTT = RTT and RTTVAR = RTT / 2; 6. If SRTT has no value, then set SRTT = RTT and RTTVAR = RTT / 2;
7. Set MRTO = SRTT + 4 * RTTVAR + 200 milliseconds; 7. Set MRTO = SRTT + 4 * RTTVAR + 200 milliseconds;
8. Set ERTO to the greater of MRTO or 250 milliseconds. 8. Set ERTO to the greater of MRTO or 250 milliseconds.
A retransmission timeout occurs when the most recently transmitted A retransmission timeout occurs when the most recently transmitted
user data fragment has remained outstanding in the network for ETRO. user data fragment has remained outstanding in the network for ETRO.
When this timeout occurs, increase ERTO on an exponential backoff When this timeout occurs, increase ERTO on an exponential backoff
with an ultimate backoff cap: with an ultimate backoff cap of 10 seconds:
1. Calculate ERTO_BACKOFF = ERTO * 1.4142; 1. Calculate ERTO_BACKOFF = ERTO * 1.4142;
2. Calculate ERTO_CAPPED to be the lesser of ERTO_BACKOFF and 10 2. Calculate ERTO_CAPPED to be the lesser of ERTO_BACKOFF and 10
seconds; seconds;
3. Set ERTO to the greater of ERTO_CAPPED and MRTO. 3. Set ERTO to the greater of ERTO_CAPPED and MRTO.
3.5.2.2. Burst Avoidance 3.5.2.3. Burst Avoidance
An application's sending patterns may cause the transmission budget An application's sending patterns may cause the transmission budget
to grow to a large value but, at times, for there to be a to grow to a large value but, at times, for there to be a
comparatively small amount of data outstanding in the network. In comparatively small amount of data outstanding in the network. In
this circumstance, especially with a window-based congestion this circumstance, especially with a window-based congestion
avoidance algorithm, if the application then has a large amount of avoidance algorithm, if the application then has a large amount of
new data to send (for example, a new bulk data transfer), it could new data to send (for example, a new bulk data transfer), it could
send data into the network all at once to fill the window. This kind send data into the network all at once to fill the window. This kind
of transmission burst can jam interfaces, links, and buffers, and is of transmission burst can jam interfaces, links, and buffers, and is
undesirable. undesirable.
skipping to change at page 61, line 43 skipping to change at page 64, line 27
On receipt of an acknowledgement chunk (Section 2.3.13, On receipt of an acknowledgement chunk (Section 2.3.13,
Section 2.3.14), set DATA_PACKET_COUNT to 0. Section 2.3.14), set DATA_PACKET_COUNT to 0.
On a retransmission timeout, set DATA_PACKET_COUNT to 0. On a retransmission timeout, set DATA_PACKET_COUNT to 0.
3.5.3. Address Mobility 3.5.3. Address Mobility
Sessions are demultiplexed with a 32 bit session ID, rather than by Sessions are demultiplexed with a 32 bit session ID, rather than by
endpoint address. This allows an endpoint's address to change during endpoint address. This allows an endpoint's address to change during
an OPEN session. This can happen, for example, when switching from a an S_OPEN session. This can happen, for example, when switching from
wireless to a wired network, or when moving from one wireless base a wireless to a wired network, or when moving from one wireless base
station to another, or when a NAT restarts. station to another, or when a NAT restarts.
If the near end receives a valid packet for an OPEN session from a If the near end receives a valid packet for an S_OPEN session from a
source address that doesn't match DESTADDR, the far end might have source address that doesn't match DESTADDR, the far end might have
changed addresses. The near end SHOULD verify that the far end is changed addresses. The near end SHOULD verify that the far end is
definitively at the new address before changing DESTADDR. A definitively at the new address before changing DESTADDR. A
suggested verification method is described in Section 3.5.4.2. suggested verification method is described in Section 3.5.4.2.
3.5.4. Ping 3.5.4. Ping
If an endpoint receives a Ping chunk (Section 2.3.9) in a session in If an endpoint receives a Ping chunk (Section 2.3.9) in a session in
the OPEN state, it SHOULD construct and send a Ping Reply chunk the S_OPEN state, it SHOULD construct and send a Ping Reply chunk
(Section 2.3.10) in response if possible, copying the message (Section 2.3.10) in response if possible, copying the message
unaltered. A Ping Reply response SHOULD be sent as quickly as unaltered. A Ping Reply response SHOULD be sent as quickly as
possible following receipt of a Ping. The semantics of a Ping's possible following receipt of a Ping. The semantics of a Ping's
message is reserved for the sender; a receiver SHOULD NOT interpret message is reserved for the sender; a receiver SHOULD NOT interpret
the Ping's message. the Ping's message.
Endpoints can use the mechanism of the Ping chunk and the expected Endpoints can use the mechanism of the Ping chunk and the expected
Ping Reply for any purpose. This specification doesn't mandate any Ping Reply for any purpose. This specification doesn't mandate any
specific constraints on the format or semantics of a Ping message. A specific constraints on the format or semantics of a Ping message. A
Ping Reply MUST ONLY be sent as a response to a Ping. Ping Reply MUST ONLY be sent as a response to a Ping.
skipping to change at page 62, line 21 skipping to change at page 65, line 4
possible following receipt of a Ping. The semantics of a Ping's possible following receipt of a Ping. The semantics of a Ping's
message is reserved for the sender; a receiver SHOULD NOT interpret message is reserved for the sender; a receiver SHOULD NOT interpret
the Ping's message. the Ping's message.
Endpoints can use the mechanism of the Ping chunk and the expected Endpoints can use the mechanism of the Ping chunk and the expected
Ping Reply for any purpose. This specification doesn't mandate any Ping Reply for any purpose. This specification doesn't mandate any
specific constraints on the format or semantics of a Ping message. A specific constraints on the format or semantics of a Ping message. A
Ping Reply MUST ONLY be sent as a response to a Ping. Ping Reply MUST ONLY be sent as a response to a Ping.
Receipt of a Ping Reply implies live bidirectional connectivity. Receipt of a Ping Reply implies live bidirectional connectivity.
This specification doesn't mandate any other semantics for a Ping This specification doesn't mandate any other semantics for a Ping
Reply. Reply.
3.5.4.1. Keepalive 3.5.4.1. Keepalive
An endpoint MAY use Ping to test for live bidirectional connectivity, An endpoint can use Ping to test for live bidirectional connectivity,
to test that the far end of a session is still OPEN, to keep NAT to test that the far end of a session is still S_OPEN, to keep NAT
translations alive, and to keep firewall holes open. translations alive, and to keep firewall holes open.
An endpoint MAY use Ping to hasten detection by the far end of a near An endpoint can use Ping to hasten detection by the far end of a near
end address change. end address change.
An endpoint MAY declare a session to be defunct and dead after a An endpoint may declare a session to be defunct and dead after a
persistent failure by the far end to return Ping Replies in response persistent failure by the far end to return Ping Replies in response
to Pings. to Pings.
If used for these purposes, a Keepalive Ping SHOULD have an empty If used for these purposes, a Keepalive Ping SHOULD have an empty
message. message.
A Keepalive Ping SHOULD NOT be sent more often than once per ERTO. A Keepalive Ping SHOULD NOT be sent more often than once per ERTO.
If a corresponding Ping Reply is not received within ERTO of sending If a corresponding Ping Reply is not received within ERTO of sending
the Ping, ERTO SHOULD be increased according to Congestion Control the Ping, ERTO SHOULD be increased according to Congestion Control
(Section 3.5.2). (Section 3.5.2).
skipping to change at page 63, line 7 skipping to change at page 65, line 40
This section describes an OPTIONAL but suggested method for This section describes an OPTIONAL but suggested method for
processing and verifying a far end address change. processing and verifying a far end address change.
Let the session context contain additional variables MOB_TX_TS, Let the session context contain additional variables MOB_TX_TS,
MOB_RX_TS, and MOB_SECRET. MOB_TX_TS and MOB_RX_TS have initial MOB_RX_TS, and MOB_SECRET. MOB_TX_TS and MOB_RX_TS have initial
values of negative infinity. MOB_SECRET should be a values of negative infinity. MOB_SECRET should be a
cryptographically pseudorandom value not less than 128 bits in length cryptographically pseudorandom value not less than 128 bits in length
and known only to this end. and known only to this end.
On receipt of a packet for an OPEN session, after processing all On receipt of a packet for an S_OPEN session, after processing all
chunks in the packet: if the session is still OPEN, AND the source chunks in the packet: if the session is still S_OPEN, AND the source
address of the packet does not match DESTADDR, AND MOB_TX_TS is at address of the packet does not match DESTADDR, AND MOB_TX_TS is at
least one second in the past, then: least one second in the past, then:
1. Set MOB_TX_TS to the current time; 1. Set MOB_TX_TS to the current time;
2. Construct a Ping message comprising: a marking to indicate that 2. Construct a Ping message comprising: a marking to indicate (to
it is a mobility check, a timestamp set to MOB_TX_TS, and a this end when returned in a Ping Reply) that it is a mobility
cryptographic hash over the preceding as well as the address from check (for example, the first byte being ASCII 'M' for
which the packet was received and MOB_SECRET; and "Mobility"), a timestamp set to MOB_TX_TS, and a cryptographic
hash over the preceding as well as the address from which the
packet was received and MOB_SECRET; and
3. Send this Ping to the address from which the packet was received, 3. Send this Ping to the address from which the packet was received,
instead of DESTADDR. instead of DESTADDR.
On receipt of a Ping Reply in an OPEN session, if the Ping Reply's On receipt of a Ping Reply in an S_OPEN session, if the Ping Reply's
message is marked to indicate it is a mobility check, AND the message satisfies all of these conditions:
timestamp in the message is not more than 132 seconds in the past,
AND the timestamp in the message is greater than MOB_RX_TS, AND the o it has this end's expected marking to indicate it is a mobility
cryptographic hash matches the expected value according to the check, and
contents of the message plus the source address of the packet
containing this Ping Reply and MOB_SECRET, then: o the timestamp in the message is not more than 120 seconds in the
past, and
o the timestamp in the message is greater than MOB_RX_TS, and
o the cryptographic hash matches the expected value according to the
contents of the message plus the source address of the packet
containing this Ping Reply and MOB_SECRET,
then:
1. Set MOB_RX_TS to the timestamp in the message; and 1. Set MOB_RX_TS to the timestamp in the message; and
2. Set DESTADDR to the source address of the packet containing this 2. Set DESTADDR to the source address of the packet containing this
Ping Reply. Ping Reply.
3.5.4.3. Path MTU Discovery 3.5.4.3. Path MTU Discovery
Packetization Layer Path MTU Discovery [RFC4821] describes a method Packetization Layer Path MTU Discovery [RFC4821] describes a method
for measuring the path MTU between communicating endpoints. for measuring the path MTU between communicating endpoints.
skipping to change at page 64, line 8 skipping to change at page 66, line 51
packet is truncated. packet is truncated.
3.5.5. Close 3.5.5. Close
An endpoint may close a session at any time. Typically an endpoint An endpoint may close a session at any time. Typically an endpoint
will close a session when there have been no open flows in either will close a session when there have been no open flows in either
direction for a time. In another circumstance, an endpoint may be direction for a time. In another circumstance, an endpoint may be
ceasing operation and will close all of its sessions even if they ceasing operation and will close all of its sessions even if they
have open flows. have open flows.
To close an OPEN session in a reliable and orderly fashion, an To close an S_OPEN session in a reliable and orderly fashion, an
endpoint moves the session to the NEARCLOSE state. endpoint moves the session to the S_NEARCLOSE state.
A session that has been in the NEARCLOSE state for at least 90
seconds SHOULD move to the CLOSED state.
A session that has been in the FARCLOSE_LINGER state for at least 19 On a session transitioning from S_OPEN to S_NEARCLOSE and every 5
seconds SHOULD move to the CLOSED state. seconds thereafter while still in the S_NEARCLOSE state, send a
Session Close Request chunk (Section 2.3.17).
On a session transitioning from OPEN to NEARCLOSE and every 5 seconds A session that has been in the S_NEARCLOSE state for at least 90
thereafter while still in the NEARCLOSE state, send a Session Close seconds (allowing time to retransmit the Session Close Request
Request chunk (Section 2.3.17). multiple times) SHOULD move to the S_CLOSED state.
On a session transitioning from OPEN to the NEARCLOSE, On a session transitioning from S_OPEN to the S_NEARCLOSE,
FARCLOSE_LINGER or CLOSED state: immediately abort and terminate all S_FARCLOSE_LINGER or S_CLOSED state: immediately abort and terminate
open or closing flows. Flows only exist in OPEN sessions. all open or closing flows. Flows only exist in S_OPEN sessions.
To close an OPEN session abruptly, send a Session Close To close an S_OPEN session abruptly, send a Session Close
Acknowledgement chunk (Section 2.3.18), then move to the CLOSED Acknowledgement chunk (Section 2.3.18), then move to the S_CLOSED
state. state.
On receipt of a Session Close Request chunk for a session in the On receipt of a Session Close Request chunk for a session in the
OPEN, NEARCLOSE, or FARCLOSE_LINGER states: send a Session Close S_OPEN, S_NEARCLOSE, or S_FARCLOSE_LINGER states: send a Session
Acknowledgement chunk; then, if the session is in the OPEN state: Close Acknowledgement chunk; then, if the session is in the S_OPEN
move to the FARCLOSE_LINGER state. state: move to the S_FARCLOSE_LINGER state.
A session that has been in the S_FARCLOSE_LINGER state for at least
19 seconds (allowing time to answer 3 retransmissions of a Session
Close Request) SHOULD move to the S_CLOSED state.
On receipt of a Session Close Acknowledgement chunk for a session in On receipt of a Session Close Acknowledgement chunk for a session in
the OPEN, NEARCLOSE, or FARCLOSE_LINGER states: move to the CLOSED the S_OPEN, S_NEARCLOSE, or S_FARCLOSE_LINGER states: move to the
state. S_CLOSED state.
3.6. Flows 3.6. Flows
A flow is a unidirectional communication channel in a session for A flow is a unidirectional communication channel in a session for
transporting a correlated series of user messages from a sender to a transporting a correlated series of user messages from a sender to a
receiver. Each end of a session may have zero or more sending flows receiver. Each end of a session may have zero or more sending flows
to the other end. Each sending flow at one end has a corresponding to the other end. Each sending flow at one end has a corresponding
receiving flow at the other end. receiving flow at the other end.
3.6.1. Overview 3.6.1. Overview
skipping to change at page 67, line 17 skipping to change at page 70, line 11
end, the flow sender SHOULD close the flow and abandon all of the end, the flow sender SHOULD close the flow and abandon all of the
undelivered queued messages. The flow sender SHOULD indicate an undelivered queued messages. The flow sender SHOULD indicate an
exception to the user. exception to the user.
3.6.2. Sender 3.6.2. Sender
Each sending flow comprises the flow-specific information context Each sending flow comprises the flow-specific information context
necessary to transfer that flow's messages to the other end. Each necessary to transfer that flow's messages to the other end. Each
sending flow context includes at least: sending flow context includes at least:
o FLOW_ID: this flow's identifier; o F_FLOW_ID: this flow's identifier;
o STARTUP_OPTIONS: the set of options to send to the receiver until o STARTUP_OPTIONS: the set of options to send to the receiver until
this flow is acknowledged, including the User's Per-Flow Metadata this flow is acknowledged, including the User's Per-Flow Metadata
and, if set, the Return Flow Association; and, if set, the Return Flow Association;
o SEND_QUEUE: the unacknowledged message fragments queued in this o SEND_QUEUE: the unacknowledged message fragments queued in this
flow, initially empty; each message fragment entry comprising: flow, initially empty; each message fragment entry comprising:
* SEQUENCE_NUMBER: the sequence number of this fragment; * SEQUENCE_NUMBER: the sequence number of this fragment;
skipping to change at page 68, line 5 skipping to change at page 70, line 47
* NAK_COUNT: a count of the number of negative acknowledgements * NAK_COUNT: a count of the number of negative acknowledgements
detected for this fragment, initially 0; detected for this fragment, initially 0;
* IN_FLIGHT: a boolean flag indicating whether this fragment is * IN_FLIGHT: a boolean flag indicating whether this fragment is
currently in flight in the network, initially false; currently in flight in the network, initially false;
* TRANSMIT_SIZE: the size, in bytes, of the encoded User Data * TRANSMIT_SIZE: the size, in bytes, of the encoded User Data
chunk (including the chunk header) for this fragment when it chunk (including the chunk header) for this fragment when it
was transmitted into the network. was transmitted into the network.
o OUTSTANDING_BYTES: the sum of the TRANSMIT_SIZE of each entry in o F_OUTSTANDING_BYTES: the sum of the TRANSMIT_SIZE of each entry in
SEND_QUEUE where entry.IN_FLIGHT is true; SEND_QUEUE where entry.IN_FLIGHT is true;
o RX_BUFFER_SIZE: the most recent available buffer advertisement o RX_BUFFER_SIZE: the most recent available buffer advertisement
from the other end (Section 2.3.13, Section 2.3.14), initially from the other end (Section 2.3.13, Section 2.3.14), initially
65536 bytes; 65536 bytes;
o NEXT_SN: the next sequence number to assign to a message fragment, o NEXT_SN: the next sequence number to assign to a message fragment,
initially 1; initially 1;
o FINAL_SN: the sequence number assigned to the final message o F_FINAL_SN: the sequence number assigned to the final message
fragment of the flow, initially having no value; fragment of the flow, initially having no value;
o EXCEPTION: a boolean flag indicating whether an exception has been o EXCEPTION: a boolean flag indicating whether an exception has been
reported by the receiver, initially false; reported by the receiver, initially false;
o The state, at any time being one of the following values: OPEN, o The state, at any time being one of the following values: the open
CLOSING, COMPLETE_LINGER, CLOSED. state F_OPEN; the closing states F_CLOSING and F_COMPLETE_LINGER;
and the closed state F_CLOSED.
3.6.2.1. Startup 3.6.2.1. Startup
The application opens a new sending flow to the other end in an OPEN The application opens a new sending flow to the other end in an
session. The implementation chooses a new flow ID that is not S_OPEN session. The implementation chooses a new flow ID that is not
assigned to any other sending flow in that session in the OPEN, assigned to any other sending flow in that session in the F_OPEN,
CLOSING, or COMPLETE_LINGER states. The flow starts in the OPEN F_CLOSING, or F_COMPLETE_LINGER states. The flow starts in the
state. The STARTUP_OPTIONS for the new flow is set with the User's F_OPEN state. The STARTUP_OPTIONS for the new flow is set with the
Per-Flow Metadata (Section 2.3.11.1.1). If this flow is in return User's Per-Flow Metadata (Section 2.3.11.1.1). If this flow is in
(or response) to an OPEN receiving flow from the other end, that return (or response) to an RF_OPEN receiving flow from the other end,
flow's ID is encoded in a Return Flow Association that flow's ID is encoded in a Return Flow Association
(Section 2.3.11.1.2) option and added to STARTUP_OPTIONS. (Section 2.3.11.1.2) option and added to STARTUP_OPTIONS.
At this point the flow exists in the sender, but not the receiver. At this point the flow exists in the sender, but not the receiver.
The flow begins when user data fragments are transmitted to the The flow begins when user data fragments are transmitted to the
receiver. A sender can begin a flow in the absence of immediate user receiver. A sender can begin a flow in the absence of immediate user
data by sending a Forward Sequence Number Update (Section 3.6.2.7.1), data by sending a Forward Sequence Number Update (Section 3.6.2.7.1),
by queuing and transmitting a user data fragment that is already by queuing and transmitting a user data fragment that is already
abandoned. abandoned.
3.6.2.2. Queuing Data 3.6.2.2. Queuing Data
The application queues messages in an OPEN sending flow for The application queues messages in an F_OPEN sending flow for
transmission to the far end. The implementation divides each message transmission to the far end. The implementation divides each message
into one or more fragments for transmission in User Data chunks into one or more fragments for transmission in User Data chunks
(Section 2.3.11). Each fragment MUST be small enough so that, if (Section 2.3.11). Each fragment MUST be small enough so that, if
assembled into a Packet (Section 2.2.4) with a maximum-size common assembled into a Packet (Section 2.2.4) with a maximum-size common
header, User Data chunk header, and, if not empty, this flow's header, User Data chunk header, and, if not empty, this flow's
STARTUP_OPTIONS, the Packet will not exceed the Path MTU STARTUP_OPTIONS, the Packet will not exceed the Path MTU
(Section 3.5.4.3). (Section 3.5.4.3).
For each fragment, create a fragment entry and set For each fragment, create a fragment entry and set
fragmentEntry.SEQUENCE_NUMBER to flow.NEXT_SN, and increment fragmentEntry.SEQUENCE_NUMBER to flow.NEXT_SN, and increment
skipping to change at page 69, line 24 skipping to change at page 72, line 19
2 : This fragment is the last of a multi-fragment message. 2 : This fragment is the last of a multi-fragment message.
3 : This fragment is in the middle of a multi-fragment message. 3 : This fragment is in the middle of a multi-fragment message.
Append fragmentEntry to flow.SEND_QUEUE. Append fragmentEntry to flow.SEND_QUEUE.
3.6.2.3. Sending Data 3.6.2.3. Sending Data
A sending flow is ready to transmit if the SEND_QUEUE contains at A sending flow is ready to transmit if the SEND_QUEUE contains at
least one entry that is eligible to send and if either RX_BUFFER_SIZE least one entry that is eligible to send and if either RX_BUFFER_SIZE
is greater than OUTSTANDING_BYTES or EXCEPTION is set to true. is greater than F_OUTSTANDING_BYTES or EXCEPTION is set to true.
A SEND_QUEUE entry is eligible to send if it is not IN_FLIGHT AND at A SEND_QUEUE entry is eligible to send if it is not IN_FLIGHT AND at
least one of the following conditions holds: least one of the following conditions holds:
o The entry is not ABANDONED; or o The entry is not ABANDONED; or
o The entry is the first one in the SEND_QUEUE; or o The entry is the first one in the SEND_QUEUE; or
o The entry's SEQUENCE_NUMBER is equal to flow.FINAL_SN. o The entry's SEQUENCE_NUMBER is equal to flow.F_FINAL_SN.
If the session's transmission budget allows, a flow that is ready to If the session's transmission budget allows, a flow that is ready to
transmit is selected for transmission according to the transmit is selected for transmission according to the
implementation's prioritization scheme. The manner of flow implementation's prioritization scheme. The manner of flow
prioritization is not mandated by this specification. prioritization is not mandated by this specification.
Trim abandoned messages from the front of the queue and find the Trim abandoned messages from the front of the queue and find the
Forward Sequence Number FSN: Forward Sequence Number FSN:
1. While the SEND_QUEUE contains at least two entries, AND the first 1. While the SEND_QUEUE contains at least two entries, AND the first
skipping to change at page 70, line 24 skipping to change at page 73, line 20
receiver. While enough space remains in the packet and the flow is receiver. While enough space remains in the packet and the flow is
ready to transmit: ready to transmit:
1. Starting at the head of the SEND_QUEUE, find the first eligible 1. Starting at the head of the SEND_QUEUE, find the first eligible
fragment entry; fragment entry;
2. Encode entry into a User Data chunk (Section 2.3.11) or, if 2. Encode entry into a User Data chunk (Section 2.3.11) or, if
possible (Section 3.6.2.3.2), a Next User Data chunk possible (Section 3.6.2.3.2), a Next User Data chunk
(Section 2.3.12); (Section 2.3.12);
3. If present, set chunk.flowID to flow.FLOW_ID; 3. If present, set chunk.flowID to flow.F_FLOW_ID;
4. If present, set chunk.sequenceNumber to entry.SEQUENCE_NUMBER; 4. If present, set chunk.sequenceNumber to entry.SEQUENCE_NUMBER;
5. If present, set chunk.fsnOffset to entry.SEQUENCE_NUMBER - FSN; 5. If present, set chunk.fsnOffset to entry.SEQUENCE_NUMBER - FSN;
6. Set chunk.fragmentControl to entry.FRA; 6. Set chunk.fragmentControl to entry.FRA;
7. Set chunk.abandon to entry.ABANDONED; 7. Set chunk.abandon to entry.ABANDONED;
8. If entry.SEQUENCE_NUMBER equals flow.FINAL_SN: set chunk.final 8. If entry.SEQUENCE_NUMBER equals flow.F_FINAL_SN: set chunk.final
to true; else set chunk.final to false; to true; else set chunk.final to false;
9. If any options are being sent with this chunk: set 9. If any options are being sent with this chunk: set
chunk.optionsPresent to true, assemble the options into the chunk.optionsPresent to true, assemble the options into the
chunk, and assemble a Marker to terminate the option list; chunk, and assemble a Marker to terminate the option list;
10. If entry.ABANDONED is true, set chunk.userData to empty; 10. If entry.ABANDONED is true, set chunk.userData to empty;
otherwise set chunk.userData to entry.DATA; otherwise set chunk.userData to entry.DATA;
11. If adding the assembled chunk to the packet would cause the 11. If adding the assembled chunk to the packet would cause the
skipping to change at page 71, line 49 skipping to change at page 74, line 45
3.6.2.4. Processing Acknowledgements 3.6.2.4. Processing Acknowledgements
A Data Acknowledgement Bitmap chunk (Section 2.3.13) or a Data A Data Acknowledgement Bitmap chunk (Section 2.3.13) or a Data
Acknowledgement Ranges chunk (Section 2.3.14) encodes the Acknowledgement Ranges chunk (Section 2.3.14) encodes the
acknowledgement of receipt of one or more sequence numbers of a flow, acknowledgement of receipt of one or more sequence numbers of a flow,
as well as the receiver's current receive window advertisement. as well as the receiver's current receive window advertisement.
On receipt of an acknowledgement chunk for a sending flow: On receipt of an acknowledgement chunk for a sending flow:
1. Set PRE_ACK_OUTSTANDING_BYTES to flow.OUTSTANDING_BYTES; 1. Set PRE_ACK_OUTSTANDING_BYTES to flow.F_OUTSTANDING_BYTES;
2. Set flow.STARTUP_OPTIONS to empty; 2. Set flow.STARTUP_OPTIONS to empty;
3. Set flow.RX_BUFFER_SIZE to chunk.bufferBytesAvailable; 3. Set flow.RX_BUFFER_SIZE to chunk.bufferBytesAvailable;
4. For each sequence number encoded in the acknowledgement: if there 4. For each sequence number encoded in the acknowledgement: if there
is an entry in flow.SEND_QUEUE with that sequence number and its is an entry in flow.SEND_QUEUE with that sequence number and its
IN_FLIGHT is true, then: remove entry from flow.SEND_QUEUE; and IN_FLIGHT is true, then: remove entry from flow.SEND_QUEUE; and
5. Notify the congestion control and avoidance algorithms that 5. Notify the congestion control and avoidance algorithms that
PRE_ACK_OUTSTANDING_BYTES - flow.OUTSTANDING_BYTES were PRE_ACK_OUTSTANDING_BYTES - flow.F_OUTSTANDING_BYTES were
acknowledged. Note that Negative Acknowledgements acknowledged. Note that Negative Acknowledgements
(Section 3.6.2.5) affect "TCP friendly" congestion control. (Section 3.6.2.5) affect "TCP friendly" congestion control.
3.6.2.5. Negative Acknowledgement and Loss 3.6.2.5. Negative Acknowledgement and Loss
A negative acknowledgement is inferred for an outstanding fragment if A negative acknowledgement is inferred for an outstanding fragment if
an acknowledgement is received for any other fragments sent after it an acknowledgement is received for any other fragments sent after it
in the same session. in the same session.
An implementation SHOULD consider a fragment to be lost once that An implementation SHOULD consider a fragment to be lost once that
skipping to change at page 73, line 25 skipping to change at page 76, line 20
flight. Set entry.IN_FLIGHT to false. Notify the congestion control flight. Set entry.IN_FLIGHT to false. Notify the congestion control
and avoidance algorithms of the loss. and avoidance algorithms of the loss.
3.6.2.6. Timeout 3.6.2.6. Timeout
A fragment is considered lost and no longer in flight in the network A fragment is considered lost and no longer in flight in the network
if it has remained outstanding for at least ERTO. if it has remained outstanding for at least ERTO.
The following describes an OPTIONAL method to manage transmission The following describes an OPTIONAL method to manage transmission
timeouts. This method REQUIRES that either Burst Avoidance timeouts. This method REQUIRES that either Burst Avoidance
(Section 3.5.2.2) is implemented, or that the implementation's (Section 3.5.2.3) is implemented, or that the implementation's
congestion control and avoidance algorithms will eventually stop congestion control and avoidance algorithms will eventually stop
sending new fragments into the network if acknowledgements are sending new fragments into the network if acknowledgements are
persistently not received. persistently not received.
Let the session information context contain an alarm TIMEOUT_ALARM, Let the session information context contain an alarm TIMEOUT_ALARM,
initially unset. initially unset.
On sending a packet containing at least one User Data chunk, set or On sending a packet containing at least one User Data chunk, set or
reset TIMEOUT_ALARM to fire in ERTO. reset TIMEOUT_ALARM to fire in ERTO.
skipping to change at page 73, line 50 skipping to change at page 76, line 45
1. Set ANY_LOSS = false; 1. Set ANY_LOSS = false;
2. For each sending flow in the session, and for each entry in that 2. For each sending flow in the session, and for each entry in that
flow's SEND_QUEUE: flow's SEND_QUEUE:
1. If entry.IN_FLIGHT is true: set ANY_LOSS = true; and 1. If entry.IN_FLIGHT is true: set ANY_LOSS = true; and
2. Set entry.IN_FLIGHT to false. 2. Set entry.IN_FLIGHT to false.
3. If ANY_LOSS is true: perform ERTO backoff (Section 3.5.2.1); and 3. If ANY_LOSS is true: perform ERTO backoff (Section 3.5.2.2); and
4. Notify the congestion control and avoidance algorithms of the 4. Notify the congestion control and avoidance algorithms of the
timeout and, if ANY_LOSS is true, that there was loss. timeout and, if ANY_LOSS is true, that there was loss.
3.6.2.7. Abandoning Data 3.6.2.7. Abandoning Data
The application can abandon queued messages at any time and for any The application can abandon queued messages at any time and for any
reason. Example reasons include (but are not limited to): one or reason. Example reasons include (but are not limited to): one or
more fragments of a message have remained in the SEND_QUEUE for more fragments of a message have remained in the SEND_QUEUE for
longer than a specified message lifetime; a fragment has been longer than a specified message lifetime; a fragment has been
retransmitted more than a specified retransmission limit; a prior retransmitted more than a specified retransmission limit; a prior
skipping to change at page 75, line 14 skipping to change at page 78, line 14
Sender Sender
| : | :
1 |<--- Ack ID=2, seq:0-16 1 |<--- Ack ID=2, seq:0-16
2 |---> Data ID=2, seq#=25, fsnOff=9 (fsn=16) 2 |---> Data ID=2, seq#=25, fsnOff=9 (fsn=16)
3 |---> Data ID=2, seq#=26, fsnOff=10 (fsn=16) 3 |---> Data ID=2, seq#=26, fsnOff=10 (fsn=16)
4 |<--- Ack ID=2, seq:0-18 4 |<--- Ack ID=2, seq:0-18
5 |---> Data ID=2, seq#=27, fsnOff=9 (fsn=18) 5 |---> Data ID=2, seq#=27, fsnOff=9 (fsn=18)
6 |---> Data ID=2, seq#=28, fsnOff=10 (fsn=18) 6 |---> Data ID=2, seq#=28, fsnOff=10 (fsn=18)
| : | :
Normal flow with no loss. There are 9 sequence numbers in flight There are 9 sequence numbers in flight with delayed acknowledgements.
with delayed acknowledgements.
Figure 16: Normal flow with no loss
Sender Sender
| : | :
1 |<--- Ack ID=3, seq:0-30 1 |<--- Ack ID=3, seq:0-30
2 |---> Data ID=3, seq#=45, fsnOff=15 (fsn=30) 2 |---> Data ID=3, seq#=45, fsnOff=15 (fsn=30)
3 |<--- Ack ID=3, seq:0-30, 32 (nack 31:1) 3 |<--- Ack ID=3, seq:0-30, 32 (nack 31:1)
4 |---> Data ID=3, seq#=46, fsnOff=16 (fsn=30) 4 |---> Data ID=3, seq#=46, fsnOff=16 (fsn=30)
5 |<--- Ack ID=3, seq:0-30, 32, 34 (nack 31:2, 33:1) 5 |<--- Ack ID=3, seq:0-30, 32, 34 (nack 31:2, 33:1)
6 |<--- Ack ID=3, seq:0-30, 32, 34-35 (nack 31:3=lost, 33:2) 6 |<--- Ack ID=3, seq:0-30, 32, 34-35 (nack 31:3=lost, 33:2)
7 |---> Data ID=3, seq#=47, fsnOff=15 (fsn=32, abandon 31) 7 |---> Data ID=3, seq#=47, fsnOff=15 (fsn=32, abandon 31)
skipping to change at page 76, line 44 skipping to change at page 79, line 44
24 |<--- Ack ID=3, seq:0-59, 61-63 (nack 60:3=lost) 24 |<--- Ack ID=3, seq:0-59, 61-63 (nack 60:3=lost)
25 |---> Data ID=3, ABN=1, seq#=60, fsnOff=0 (fsn=60, abandon 60) 25 |---> Data ID=3, ABN=1, seq#=60, fsnOff=0 (fsn=60, abandon 60)
26 |<--- Ack ID=3, seq:0-59, 61-64 26 |<--- Ack ID=3, seq:0-59, 61-64
| : | :
27 |<--- Ack ID=3, seq:0-64 27 |<--- Ack ID=3, seq:0-64
Flow with sequence numbers 31, 33, and 60 lost in transit, and a Flow with sequence numbers 31, 33, and 60 lost in transit, and a
pause at 64. 33 is retransmitted, 31 and 60 are abandoned. Note line pause at 64. 33 is retransmitted, 31 and 60 are abandoned. Note line
25 is a Forward Sequence Number Update (Section 3.6.2.7.1). 25 is a Forward Sequence Number Update (Section 3.6.2.7.1).
Figure 17: Flow with loss
3.6.2.9. Flow Control 3.6.2.9. Flow Control
The flow receiver advertises the amount of new data it's willing to The flow receiver advertises the amount of new data it's willing to
accept from the flow sender with the bufferBytesAvailable derived accept from the flow sender with the bufferBytesAvailable derived
field of an acknowledgement (Section 2.3.13, Section 2.3.14). field of an acknowledgement (Section 2.3.13, Section 2.3.14).
The flow sender MUST NOT send new data into the network if The flow sender MUST NOT send new data into the network if
flow.OUTSTANDING_BYTES is greater than or equal to the most recently flow.F_OUTSTANDING_BYTES is greater than or equal to the most
received buffer advertisement, unless flow.EXCEPTION is true recently received buffer advertisement, unless flow.EXCEPTION is true
(Section 3.6.2.3). (Section 3.6.2.3).
3.6.2.9.1. Buffer Probe 3.6.2.9.1. Buffer Probe
The flow sender is suspended if the most recently received buffer The flow sender is suspended if the most recently received buffer
advertisement is zero and the flow hasn't been rejected by the advertisement is zero and the flow hasn't been rejected by the
receiver; that is, while RX_BUFFER_SIZE is zero AND EXCEPTION is receiver; that is, while RX_BUFFER_SIZE is zero AND EXCEPTION is
false. To guard against potentially lost acknowledgements that might false. To guard against potentially lost acknowledgements that might
reopen the receive window, a suspended flow sender SHOULD send a reopen the receive window, a suspended flow sender SHOULD send a
packet comprising a Buffer Probe chunk (Section 2.3.15) for this flow packet comprising a Buffer Probe chunk (Section 2.3.15) for this flow
skipping to change at page 77, line 36 skipping to change at page 80, line 38
suspended. suspended.
3.6.2.10. Exception 3.6.2.10. Exception
The flow receiver can reject the flow at any time and for any reason. The flow receiver can reject the flow at any time and for any reason.
The flow receiver sends a Flow Exception Report (Section 2.3.16) when The flow receiver sends a Flow Exception Report (Section 2.3.16) when
it has rejected a flow. it has rejected a flow.
On receiving a Flow Exception Report for a sending flow: On receiving a Flow Exception Report for a sending flow:
1. If the flow is OPEN, close the flow (Section 3.6.2.11) and notify 1. If the flow is F_OPEN, close the flow (Section 3.6.2.11) and
the user that the far end reported an exception with the encoded notify the user that the far end reported an exception with the
exception code; encoded exception code;
2. Set the EXCEPTION flag to true; and 2. Set the EXCEPTION flag to true; and
3. For each entry in SEND_QUEUE: set entry.ABANDONED = true. 3. For each entry in SEND_QUEUE: set entry.ABANDONED = true.
3.6.2.11. Close 3.6.2.11. Close
A sending flow is closed by the user or as a result of an exception. A sending flow is closed by the user or as a result of an exception.
To close an OPEN flow: To close an F_OPEN flow:
1. Move to the F_CLOSING state;
1. Move to the CLOSING state;
2. If the SEND_QUEUE is not empty, AND the tail entry of the 2. If the SEND_QUEUE is not empty, AND the tail entry of the
SEND_QUEUE has a sequence number of NEXT_SN - 1, AND the tail SEND_QUEUE has a sequence number of NEXT_SN - 1, AND the tail
entry.EVER_SENT is false: set FINAL_SN to entry.SEQUENCE_NUMBER; entry.EVER_SENT is false: set F_FINAL_SN to
else entry.SEQUENCE_NUMBER; else
3. The SEND_QUEUE is empty, OR the tail entry does not have a 3. The SEND_QUEUE is empty, OR the tail entry does not have a
sequence number of NEXT_SN - 1, OR the tail entry.EVER_SENT is sequence number of NEXT_SN - 1, OR the tail entry.EVER_SENT is
true: enqueue a new SEND_QUEUE entry with entry.SEQUENCE_NUMBER = true: enqueue a new SEND_QUEUE entry with entry.SEQUENCE_NUMBER =
flow.NEXT_SN, entry.FRA = 0, and entry.ABANDONED = true, and set flow.NEXT_SN, entry.FRA = 0, and entry.ABANDONED = true, and set
flow.FINAL_SN to entry.SEQUENCE_NUMBER. flow.F_FINAL_SN to entry.SEQUENCE_NUMBER.
A CLOSING sending flow is complete when its SEND_QUEUE transitions to An F_CLOSING sending flow is complete when its SEND_QUEUE transitions
empty, indicating that all sequence numbers including the FINAL_SN to empty, indicating that all sequence numbers including the FINAL_SN
have been acknowledged by the other end. have been acknowledged by the other end.
When a CLOSING sending flow becomes complete, move to the When an F_CLOSING sending flow becomes complete, move to the
COMPLETE_LINGER state. F_COMPLETE_LINGER state.
A sending flow MUST remain in the COMPLETE_LINGER state for at least A sending flow MUST remain in the F_COMPLETE_LINGER state for at
130 seconds. After at least 130 seconds, move to the CLOSED state. least 130 seconds. After at least 130 seconds, move to the F_CLOSED
The sending flow is now closed, its resources can be reclaimed, and state. The sending flow is now closed, its resources can be
its FLOW_ID MAY be used for a new sending flow. reclaimed, and its F_FLOW_ID MAY be used for a new sending flow.
3.6.3. Receiver 3.6.3. Receiver
Each receiving flow comprises the flow-specific information context Each receiving flow comprises the flow-specific information context
necessary to receive that flow's messages from the sending end and necessary to receive that flow's messages from the sending end and
deliver completed messages to the user. Each receiving flow context deliver completed messages to the user. Each receiving flow context
includes at least: includes at least:
o FLOW_ID: this flow's identifier; o RF_FLOW_ID: this flow's identifier;
o SEQUENCE_SET: the set of all sequence numbers seen in this o SEQUENCE_SET: the set of all sequence numbers seen in this
receiving flow, whether received or abandoned, initially empty; receiving flow, whether received or abandoned, initially empty;
o FINAL_SN: the final sequence number of the flow, initially having o RF_FINAL_SN: the final sequence number of the flow, initially
no value; having no value;
o RECV_BUFFER: the message fragments waiting to be delivered to the o RECV_BUFFER: the message fragments waiting to be delivered to the
user, sorted by sequence number in ascending order, initially user, sorted by sequence number in ascending order, initially
empty; each message fragment entry comprising: empty; each message fragment entry comprising:
* SEQUENCE_NUMBER: the sequence number of this fragment; * SEQUENCE_NUMBER: the sequence number of this fragment;
* DATA: this fragment's user data; and * DATA: this fragment's user data; and
* FRA: the fragment control value for this message fragment, * FRA: the fragment control value for this message fragment,
having one of the values enumerated for that purpose in User having one of the values enumerated for that purpose in User
Data (Section 2.3.11). Data (Section 2.3.11).
o BUFFERED_SIZE: the sum of the lengths of each fragment in o BUFFERED_SIZE: the sum of the lengths of each fragment in
RECV_BUFFER plus any additional storage overhead for the fragments RECV_BUFFER plus any additional storage overhead for the fragments
incurred by the implementation, in bytes; incurred by the implementation, in bytes;
o BUFFER_CAPACITY: the desired maximum size for the receive buffer, o BUFFER_CAPACITY: the desired maximum size for the receive buffer,
in bytes; in bytes;
skipping to change at page 79, line 22 skipping to change at page 82, line 24
o PREV_RWND: the most recent receive window advertisement sent in an o PREV_RWND: the most recent receive window advertisement sent in an
acknowledgement, in 1024-byte blocks, initially having no value; acknowledgement, in 1024-byte blocks, initially having no value;
o SHOULD_ACK: whether or not an acknowledgement should be sent for o SHOULD_ACK: whether or not an acknowledgement should be sent for
this flow, initially false; this flow, initially false;
o EXCEPTION_CODE: the exception code to report to the sender when o EXCEPTION_CODE: the exception code to report to the sender when
the flow has been rejected, initially 0; the flow has been rejected, initially 0;
o The state, at any time being one of the following values: OPEN, o The state, at any time being one of the following values: the open
REJECTED, COMPLETE_LINGER, CLOSED. state RF_OPEN; the closing states RF_REJECTED and
RF_COMPLETE_LINGER; and the closed state RF_CLOSED.
3.6.3.1. Startup 3.6.3.1. Startup
A new receiving flow starts on receipt of a User Data chunk A new receiving flow starts on receipt of a User Data chunk
(Section 2.3.11) encoding a flow ID not belonging to any other (Section 2.3.11) encoding a flow ID not belonging to any other
receiving flow in the same session in the OPEN, REJECTED, or receiving flow in the same session in the RF_OPEN, RF_REJECTED, or
COMPLETE_LINGER states. RF_COMPLETE_LINGER states.
On receipt of such a User Data chunk: On receipt of such a User Data chunk:
1. Set temporary variables METADATA, ASSOCIATED_FLOWID, and 1. Set temporary variables METADATA, ASSOCIATED_FLOWID, and
ASSOCIATION to each have no value; ASSOCIATION to each have no value;
2. Create a new receiving flow context in this session, setting its 2. Create a new receiving flow context in this session, setting its
FLOW_ID to the flow ID encoded in the opening User Data chunk, RF_FLOW_ID to the flow ID encoded in the opening User Data
and set to the OPEN state; chunk, and set to the RF_OPEN state;
3. If the opening User Data chunk encodes a User's Per-Flow 3. If the opening User Data chunk encodes a User's Per-Flow
Metadata option (Section 2.3.11.1.1), set METADATA to Metadata option (Section 2.3.11.1.1), set METADATA to
option.userMetadata; option.userMetadata;
4. If the opening User Data chunk encodes a Return Flow Association 4. If the opening User Data chunk encodes a Return Flow Association
option (Section 2.3.11.1.2), set ASSOCIATED_FLOWID to option (Section 2.3.11.1.2), set ASSOCIATED_FLOWID to
option.flowID; option.flowID;
5. If METADATA has no value, the receiver MUST reject the flow 5. If METADATA has no value, the receiver MUST reject the flow
(Section 3.6.3.7), moving it to the REJECTED state; (Section 3.6.3.7), moving it to the RF_REJECTED state;
6. If ASSOCIATED_FLOWID has a value, then if there is no sending 6. If ASSOCIATED_FLOWID has a value, then if there is no sending
flow in the same session with a flow ID of ASSOCIATED_FLOWID, flow in the same session with a flow ID of ASSOCIATED_FLOWID,
the receiver MUST reject the flow, moving it to the REJECTED the receiver MUST reject the flow, moving it to the RF_REJECTED
state; otherwise set ASSOCIATION to the indicated sending flow; state; otherwise set ASSOCIATION to the indicated sending flow;
7. If ASSOCIATION indicates a sending flow AND that sending flow's 7. If ASSOCIATION indicates a sending flow AND that sending flow's
state is not OPEN, the receiver MUST reject this receiving flow, state is not F_OPEN, the receiver MUST reject this receiving
moving it to the REJECTED state; flow, moving it to the RF_REJECTED state;
8. If the opening User Data chunk encodes any unrecognized option 8. If the opening User Data chunk encodes any unrecognized option
with a type code less than 8192 (Section 2.3.11.1), the receiver with a type code less than 8192 (Section 2.3.11.1), the receiver
MUST reject the flow, moving it to the REJECTED state; MUST reject the flow, moving it to the RF_REJECTED state;
9. If this new receiving flow is still OPEN, then: notify the user 9. If this new receiving flow is still RF_OPEN, then: notify the
that a new receiving flow has opened, including the METADATA user that a new receiving flow has opened, including the
and, if present, the ASSOCIATION, and set flow.BUFFER_CAPACITY METADATA and, if present, the ASSOCIATION, and set
according to the user; flow.BUFFER_CAPACITY according to the user;
10. Perform the normal data processing (Section 3.6.3.2) for the 10. Perform the normal data processing (Section 3.6.3.2) for the
opening User Data chunk; and opening User Data chunk; and
11. Set this session's ACK_NOW to true. 11. Set this session's ACK_NOW to true.
3.6.3.2. Receiving Data 3.6.3.2. Receiving Data
A User Data chunk (Section 2.3.11) or a Next User Data chunk A User Data chunk (Section 2.3.11) or a Next User Data chunk
(Section 2.3.12) encodes one fragment of a user data message of a (Section 2.3.12) encodes one fragment of a user data message of a
flow, as well as the flow's Forward Sequence Number and potentially flow, as well as the flow's Forward Sequence Number and potentially
optional parameters (Section 2.3.11.1). optional parameters (Section 2.3.11.1).
On receipt of a User Data or Next User Data chunk: On receipt of a User Data or Next User Data chunk:
1. If chunk.flowID doesn't indicate an existing receiving flow in 1. If chunk.flowID doesn't indicate an existing receiving flow in
the same session in the OPEN, REJECTED, or COMPLETE_LINGER the same session in the RF_OPEN, RF_REJECTED, or
state, perform the steps at Startup (Section 3.6.3.1) to start a RF_COMPLETE_LINGER state, perform the steps at Startup
new receiving flow; (Section 3.6.3.1) to start a new receiving flow;
2. Retrieve the receiving flow context for the flow indicated by 2. Retrieve the receiving flow context for the flow indicated by
chunk.flowID; chunk.flowID;
3. Set flow.SHOULD_ACK to true; 3. Set flow.SHOULD_ACK to true;
4. If the flow is OPEN AND the chunk encodes any unrecognized 4. If the flow is RF_OPEN AND the chunk encodes any unrecognized
option with a type code less than 8192 (Section 2.3.11.1), the option with a type code less than 8192 (Section 2.3.11.1), the
flow MUST be rejected: notify the user of an exception, and flow MUST be rejected: notify the user of an exception, and
reject the flow (Section 3.6.3.7), moving it to the REJECTED reject the flow (Section 3.6.3.7), moving it to the RF_REJECTED
state; state;
5. If the flow is not in the OPEN state: set session.ACK_NOW to 5. If the flow is not in the RF_OPEN state: set session.ACK_NOW to
true; true;
6. If flow.PREV_RWND has a value and that value is less than 2 6. If flow.PREV_RWND has a value and that value is less than 2
blocks, set session.ACK_NOW to true; blocks, set session.ACK_NOW to true;
7. If chunk.abandon is true: set session.ACK_NOW to true; 7. If chunk.abandon is true: set session.ACK_NOW to true;
8. If flow.SEQUENCE_SET has any gaps (that is, if it doesn't 8. If flow.SEQUENCE_SET has any gaps (that is, if it doesn't
contain every sequence number from 0 through and including the contain every sequence number from 0 through and including the
highest sequence number in the set), set session.ACK_NOW to highest sequence number in the set), set session.ACK_NOW to
true; true;
9. If flow.SEQUENCE_SET contains chunk.sequenceNumber, then this 9. If flow.SEQUENCE_SET contains chunk.sequenceNumber, then this
chunk is a duplicate: set session.ACK_NOW to true; chunk is a duplicate: set session.ACK_NOW to true;
10. If flow.SEQUENCE_SET doesn't contain chunk.sequenceNumber, AND 10. If flow.SEQUENCE_SET doesn't contain chunk.sequenceNumber, AND
chunk.final is true, AND flow.FINAL_SN has no value, then: set chunk.final is true, AND flow.RF_FINAL_SN has no value, then:
flow.FINAL_SN to chunk.sequenceNumber, and set session.ACK_NOW set flow.RF_FINAL_SN to chunk.sequenceNumber, and set
to true; session.ACK_NOW to true;
11. If the flow is in the OPEN state, AND flow.SEQUENCE_SET doesn't 11. If the flow is in the RF_OPEN state, AND flow.SEQUENCE_SET
contain chunk.sequenceNumber, AND chunk.abandon is false, then: doesn't contain chunk.sequenceNumber, AND chunk.abandon is
create a new RECV_BUFFER entry for this chunk's data and set false, then: create a new RECV_BUFFER entry for this chunk's
entry.SEQUENCE_NUMBER to chunk.sequenceNumber, entry.DATA to data and set entry.SEQUENCE_NUMBER to chunk.sequenceNumber,
chunk.userData, and entry.FRA to chunk.fragmentControl, and entry.DATA to chunk.userData, and entry.FRA to
insert this new entry into flow.RECV_BUFFER; chunk.fragmentControl, and insert this new entry into
flow.RECV_BUFFER;
12. Add to flow.SEQUENCE_SET the range of sequence numbers from 0 12. Add to flow.SEQUENCE_SET the range of sequence numbers from 0
through and including the chunk.forwardSequenceNumber derived through and including the chunk.forwardSequenceNumber derived
field; field;
13. Add chunk.sequenceNumber to flow.SEQUENCE_SET; 13. Add chunk.sequenceNumber to flow.SEQUENCE_SET;
14. If flow.SEQUENCE_SET now has any gaps, set session.ACK_NOW to 14. If flow.SEQUENCE_SET now has any gaps, set session.ACK_NOW to
true; true;
15. If session.ACK_NOW is false and session.DELACK_ALARM is not set: 15. If session.ACK_NOW is false and session.DELACK_ALARM is not set:
set session.DELACK_ALARM to fire in 200 milliseconds; and set session.DELACK_ALARM to fire in 200 milliseconds; and
16. Attempt delivery of completed messages in this flow's 16. Attempt delivery of completed messages in this flow's
RECV_BUFFER to the user (Section 3.6.3.3). RECV_BUFFER to the user (Section 3.6.3.3).
After processing all chunks in a packet containing at least one User After processing all chunks in a packet containing at least one User
Data chunk, increment session.RX_DATA_PACKETS by one. If Data chunk, increment session.RX_DATA_PACKETS by one. If
session.RX_DATA_PACKETS is at least two, set session.ACK_NOW to true. session.RX_DATA_PACKETS is at least two, set session.ACK_NOW to true.
A receiving flow that is not in the CLOSED state is ready to send an A receiving flow that is not in the RF_CLOSED state is ready to send
acknowledgement if its SHOULD_ACK flag is set. Acknowledgements for an acknowledgement if its SHOULD_ACK flag is set. Acknowledgements
receiving flows that are ready are sent either opportunistically by for receiving flows that are ready are sent either opportunistically
piggybacking on a packet that's already sending user data or an by piggybacking on a packet that's already sending user data or an
acknowledgement (Section 3.6.3.4.6), or when the session's ACK_NOW acknowledgement (Section 3.6.3.4.6), or when the session's ACK_NOW
flag is set (Section 3.6.3.4.5). flag is set (Section 3.6.3.4.5).
3.6.3.3. Buffering and Delivering Data 3.6.3.3. Buffering and Delivering Data
A receiving flow's information context contains a RECV_BUFFER for A receiving flow's information context contains a RECV_BUFFER for
reordering, reassembling, and holding the user data messages of the reordering, reassembling, and holding the user data messages of the
flow. Only complete messages are delivered to the user; an flow. Only complete messages are delivered to the user; an
implementation MUST NOT deliver partially received messages except by implementation MUST NOT deliver partially received messages except by
special arrangement with the user. special arrangement with the user.
skipping to change at page 83, line 50 skipping to change at page 87, line 5
2. If LAST_ENTRY.SEQUENCE_NUMBER is less than CSN: this segment 2. If LAST_ENTRY.SEQUENCE_NUMBER is less than CSN: this segment
is incomplete and abandoned, so remove and discard the is incomplete and abandoned, so remove and discard the
entries for this segment from RECV_BUFFER; otherwise, entries for this segment from RECV_BUFFER; otherwise,
3. LAST_ENTRY.SEQUENCE_NUMBER is equal to CSN and LAST_ENTRY.FRA 3. LAST_ENTRY.SEQUENCE_NUMBER is equal to CSN and LAST_ENTRY.FRA
is not 2-end: this segment is incomplete but still in is not 2-end: this segment is incomplete but still in
progress. Ordered delivery is no longer possible until at progress. Ordered delivery is no longer possible until at
least one more fragment is received. Stop. least one more fragment is received. Stop.
If flow.FINAL_SN has a value and is equal to CSN, AND RECV_BUFFER is If flow.RF_FINAL_SN has a value and is equal to CSN, AND RECV_BUFFER
empty: all complete messages have been delivered to the user, so is empty: all complete messages have been delivered to the user, so
notify the user that the flow is complete. notify the user that the flow is complete.
3.6.3.4. Acknowledging Data 3.6.3.4. Acknowledging Data
A flow receiver SHOULD acknowledge all user data sequence numbers A flow receiver SHOULD acknowledge all user data sequence numbers
seen in that flow. Acknowledgements drive the sender's congestion seen in that flow. Acknowledgements drive the sender's congestion
control and avoidance algorithms, clear data from the sender's control and avoidance algorithms, clear data from the sender's
buffers, and in some sender implementations clock new data into the buffers, and in some sender implementations clock new data into the
network, and therefore must be accurate and timely. network, and therefore must be accurate and timely.
skipping to change at page 84, line 29 skipping to change at page 87, line 33
to receive timely notification about the receiver's disposition of to receive timely notification about the receiver's disposition of
the flow, particularly in unusual or exceptional circumstances, so the flow, particularly in unusual or exceptional circumstances, so
that the circumstances can be addressed if possible. that the circumstances can be addressed if possible.
Therefore, a flow receiver SHOULD send an acknowledgement for a flow Therefore, a flow receiver SHOULD send an acknowledgement for a flow
as soon as is practical in any of the following circumstances: as soon as is practical in any of the following circumstances:
o On receipt of a User Data chunk that starts a new flow; o On receipt of a User Data chunk that starts a new flow;
o On receipt of a User Data or Next User Data chunk if the flow is o On receipt of a User Data or Next User Data chunk if the flow is
not in the OPEN state; not in the RF_OPEN state;
o On receipt of a User Data chunk where, before processing the o On receipt of a User Data chunk where, before processing the
chunk, the SEQUENCE_SET of the indicated flow does not contain chunk, the SEQUENCE_SET of the indicated flow does not contain
every sequence number between 0 and the highest sequence number in every sequence number between 0 and the highest sequence number in
the set (that is, if there was a sequence number gap before the set (that is, if there was a sequence number gap before
processing the chunk); processing the chunk);
o On receipt of a User Data chunk where, after processing the chunk, o On receipt of a User Data chunk where, after processing the chunk,
the flow's SEQUENCE_SET does not contain every sequence number the flow's SEQUENCE_SET does not contain every sequence number
between 0 and the highest sequence number in the set (that is, if between 0 and the highest sequence number in the set (that is, if
skipping to change at page 85, line 49 skipping to change at page 89, line 5
3.6.3.4.3. Constructing 3.6.3.4.3. Constructing
The Data Acknowledgement Bitmap chunk (Section 2.3.13) and Data The Data Acknowledgement Bitmap chunk (Section 2.3.13) and Data
Acknowledgement Ranges chunk (Section 2.3.14) encode a receiving Acknowledgement Ranges chunk (Section 2.3.14) encode a receiving
flow's SEQUENCE_SET and its receive window advertisement. The two flow's SEQUENCE_SET and its receive window advertisement. The two
chunks are semantically equivalent; implementations SHOULD send chunks are semantically equivalent; implementations SHOULD send
whichever provides the most compact encoding of the SEQUENCE_SET. whichever provides the most compact encoding of the SEQUENCE_SET.
When assembling an acknowledgement for a receiving flow: When assembling an acknowledgement for a receiving flow:
1. If the flow's state is REJECTED, first assemble a Flow Exception 1. If the flow's state is RF_REJECTED, first assemble a Flow
Report chunk (Section 2.3.16) for flow.flowID; Exception Report chunk (Section 2.3.16) for flow.flowID;
2. Choose the acknowledgement chunk type that most compactly encodes 2. Choose the acknowledgement chunk type that most compactly encodes
flow.SEQUENCE_SET; flow.SEQUENCE_SET;
3. Use the method described in Flow Control (Section 3.6.3.5) to 3. Use the method described in Flow Control (Section 3.6.3.5) to
determine the value for the acknowledgement chunk's determine the value for the acknowledgement chunk's
bufferBlocksAvailable field; bufferBlocksAvailable field;
3.6.3.4.4. Delayed Acknowledgement 3.6.3.4.4. Delayed Acknowledgement
skipping to change at page 88, line 24 skipping to change at page 91, line 24
9 |---> Ack ID=3, seq:0-30, 32, 34-46 9 |---> Ack ID=3, seq:0-30, 32, 34-46
10 |<--- Data ID=3, seq#=47, fsnOff=15 (fsn=32) 10 |<--- Data ID=3, seq#=47, fsnOff=15 (fsn=32)
11 |---> Ack ID=3, seq:0-32, 34-47 11 |---> Ack ID=3, seq:0-32, 34-47
12 |<--- Data ID=3, seq#=33, fsnOff=1 (fsn=32) 12 |<--- Data ID=3, seq#=33, fsnOff=1 (fsn=32)
13 |---> Ack ID=3, seq#=0-47 13 |---> Ack ID=3, seq#=0-47
14 |<--- Data ID=3, seq#=48, fsnOff=16 (fsn=32) 14 |<--- Data ID=3, seq#=48, fsnOff=16 (fsn=32)
15 |<--- Data ID=3, seq#=49, fsnOff=17 (fsn=32) 15 |<--- Data ID=3, seq#=49, fsnOff=17 (fsn=32)
16 |---> Ack ID=3, seq#=0-49 16 |---> Ack ID=3, seq#=0-49
| : | :
Flow with sequence numbers 31 and 33 lost in transit, 31 abandoned Figure 18: Flow with sequence numbers 31 and 33 lost in transit, 31
and 33 retransmitted. abandoned and 33 retransmitted.
3.6.3.5. Flow Control 3.6.3.5. Flow Control
The flow receiver maintains a buffer for reassembling and reordering The flow receiver maintains a buffer for reassembling and reordering
messages for delivery to the user (Section 3.6.3.3). The messages for delivery to the user (Section 3.6.3.3). The
implementation and the user may wish to limit the amount of resources implementation and the user may wish to limit the amount of resources
(including buffer memory) that a flow is allowed to use. (including buffer memory) that a flow is allowed to use.
RTMFP provides a means for each receiving flow to govern the amount RTMFP provides a means for each receiving flow to govern the amount
of data sent by the sender, by way of the bufferBytesAvailable of data sent by the sender, by way of the bufferBytesAvailable
skipping to change at page 89, line 43 skipping to change at page 92, line 43
3.6.3.6. Receiving a Buffer Probe 3.6.3.6. Receiving a Buffer Probe
A Buffer Probe chunk (Section 2.3.15) is sent by the flow sender A Buffer Probe chunk (Section 2.3.15) is sent by the flow sender
(Section 3.6.2.9.1) to request the current receive window (Section 3.6.2.9.1) to request the current receive window
advertisement (in the form of an acknowledgement) from the flow advertisement (in the form of an acknowledgement) from the flow
receiver. receiver.
On receipt of a Buffer Probe chunk: On receipt of a Buffer Probe chunk:
1. If chunk.flowID doesn't belong to a receiving flow in the same 1. If chunk.flowID doesn't belong to a receiving flow in the same
session in the OPEN, REJECTED, or COMPLETE_LINGER state: ignore session in the RF_OPEN, RF_REJECTED, or RF_COMPLETE_LINGER state:
this Buffer Probe; otherwise, ignore this Buffer Probe; otherwise,
2. Retrieve the receiving flow context for the flow indicated by 2. Retrieve the receiving flow context for the flow indicated by
chunk.flowID; then chunk.flowID; then
3. Set flow.SHOULD_ACK to true; and 3. Set flow.SHOULD_ACK to true; and
4. Set session.ACK_NOW to true. 4. Set session.ACK_NOW to true.
3.6.3.7. Rejecting a Flow 3.6.3.7. Rejecting a Flow
A receiver can reject an OPEN flow at any time and for any reason. A receiver can reject an RF_OPEN flow at any time and for any reason.
To reject a receiving flow in the OPEN state: To reject a receiving flow in the RF_OPEN state:
1. Move to the REJECTED state; 1. Move to the RF_REJECTED state;
2. Discard all entries in flow.RECV_BUFFER, as they are no longer 2. Discard all entries in flow.RECV_BUFFER, as they are no longer
relevant; relevant;
3. If the user rejected the flow, set flow.EXCEPTION_CODE to the 3. If the user rejected the flow, set flow.EXCEPTION_CODE to the
exception code indicated by the user; otherwise the flow was exception code indicated by the user; otherwise the flow was
rejected automatically by the implementation, so the exception rejected automatically by the implementation, so the exception
code is 0; code is 0;
4. Set flow.SHOULD_ACK to true; and 4. Set flow.SHOULD_ACK to true; and
5. Set session.ACK_NOW to true. 5. Set session.ACK_NOW to true.
The receiver indicates that it has rejected a flow by sending a Flow The receiver indicates that it has rejected a flow by sending a Flow
Exception Report chunk (Section 2.3.16) with every acknowledgement Exception Report chunk (Section 2.3.16) with every acknowledgement
(Section 3.6.3.4.3) for a flow in the REJECTED state. (Section 3.6.3.4.3) for a flow in the RF_REJECTED state.
3.6.3.8. Close 3.6.3.8. Close
A receiving flow is complete when every sequence number from 0 A receiving flow is complete when every sequence number from 0
through and including the final sequence number has been received; through and including the final sequence number has been received;
that is, when flow.FINAL_SN has a value and flow.SEQUENCE_SET that is, when flow.RF_FINAL_SN has a value and flow.SEQUENCE_SET
contains every sequence number from 0 through flow.FINAL_SN, contains every sequence number from 0 through flow.RF_FINAL_SN,
inclusive. inclusive.
When an OPEN or REJECTED receiving flow becomes complete, move to the When an RF_OPEN or RF_REJECTED receiving flow becomes complete, move
COMPLETE_LINGER state, set flow.SHOULD_ACK to true, and set to the RF_COMPLETE_LINGER state, set flow.SHOULD_ACK to true, and set
session.ACK_NOW to true. session.ACK_NOW to true.
A receiving flow SHOULD remain in the COMPLETE_LINGER state for 120 A receiving flow SHOULD remain in the RF_COMPLETE_LINGER state for
seconds. After 120 seconds, move to the CLOSED state. The receiving 120 seconds. After 120 seconds, move to the RF_CLOSED state. The
flow is now closed, and its resources can be reclaimed once all receiving flow is now closed, and its resources can be reclaimed once
complete messages in flow.RECV_BUFFER have been delivered to the user all complete messages in flow.RECV_BUFFER have been delivered to the
(Section 3.6.3.3). The same flow ID might be used for a new flow by user (Section 3.6.3.3). The same flow ID might be used for a new
the sender after this point. flow by the sender after this point.
Discussion: The flow sender detects that the flow is complete on Discussion: The flow sender detects that the flow is complete on
receiving an acknowledgement of all sequence numbers of the flow. receiving an acknowledgement of all sequence numbers of the flow.
This can't happen until after the receiver has detected that the flow This can't happen until after the receiver has detected that the flow
is complete and acknowledged all of the sequence numbers. The is complete and acknowledged all of the sequence numbers. The
receiver's COMPLETE_LINGER period is two minutes (one Maximum Segment receiver's RF_COMPLETE_LINGER period is two minutes (one Maximum
Lifetime (MSL)), which allows any in-flight packets to drain from the Segment Lifetime (MSL)), which allows any in-flight packets to drain
network without being misidentified, and gives the sender an from the network without being misidentified, and gives the sender an
opportunity to retransmit any sequence numbers if the completing opportunity to retransmit any sequence numbers if the completing
acknowledgement is lost. The sender's COMPLETE_LINGER period is at acknowledgement is lost. The sender's F_COMPLETE_LINGER period is at
least two minutes plus 10 seconds, and doesn't begin until the least two minutes plus 10 seconds, and doesn't begin until the
completing acknowledgement is received; therefore, the same flow completing acknowledgement is received; therefore, the same flow
identifier won't be re-used by the flow sender for a new sending flow identifier won't be re-used by the flow sender for a new sending flow
for at least 10 seconds after the flow receiver has closed the for at least 10 seconds after the flow receiver has closed the
receiving flow context. This ensures correct operation independent receiving flow context. This ensures correct operation independent
of network delay and even when the sender's clock runs up to 8 of network delay and even when the sender's clock runs up to 8
percent faster than the receiver's. percent faster than the receiver's.
4. IANA Considerations 4. IANA Considerations
 End of changes. 146 change blocks. 
341 lines changed or deleted 458 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/