4.6.2. Bidirectional Operation
This section describes the basic bidirectional operation and sequence
of events/triggers of the RMD-QOSM. The following basic operation
cases are distinguished:
* Successful and unsuccessful reservation (Section 4.6.2.1);
* Refresh reservation (Section 4.6.2.2);
* Modification of aggregated reservation (Section 4.6.2.3);
* Release procedure (Section 4.6.2.4);
* Severe congestion handling (Section 4.6.2.5);
* Admission control using congestion notification based on probing
(Section 4.6.2.6).
It is important to emphasize that the content of this section is used
for the specification of the following RMD-QOSM/QoS-NSLP signaling
schemes, when basic unidirectional operation is assumed:
* "per-flow congestion notification based on probing";
* "per-flow RMD NSIS measurement-based admission control",
* "per-flow RMD reservation-based" in combination with the "severe
congestion handling by the RMD-QOSM refresh" procedure;
* "per-flow RMD reservation-based" in combination with the "severe
congestion handling by proportional data packet marking"
procedure;
* "per-aggregate RMD reservation-based" in combination with the
"severe congestion handling by the RMD-QOSM refresh" procedure;
* "per-aggregate RMD reservation-based" in combination with the
"severe congestion handling by proportional data packet marking"
procedure.
For more details, please see Section 3.2.3.
In particular, the functionality described in Sections 4.6.2.1,
4.6.2.2, 4.6.2.3, 4.6.2.4, and 4.6.2.5 applies to the RMD
reservation-based and NSIS measurement-based admission control
methods. The described functionality in Section 4.6.2.6 applies to
the admission control procedure that uses the congestion notification
based on probing. The QNE Edge nodes maintain either per-flow QoS-
NSLP operational and reservation states or aggregated QoS-NSLP
operational and reservation states.
RMD-QOSM assumes that asymmetric routing MAY be applied in the RMD
domain. Combined sender-receiver initiated reservation cannot be
efficiently done in the RMD domain because upstream NTLP states are
not stored in Interior routers.
Therefore, the bidirectional operation SHOULD be performed by two
sender-initiated reservations (sender&sender). We assume that the
QNE Edge nodes are common for both upstream and downstream
directions, therefore, the two reservations/sessions can be bound at
the QNE Edge nodes. Note that if this is not the case, then the
bidirectional procedure could be managed and maintained by nodes
located outside the RMD domain, by using other procedures than the
ones defined in RMD-QOSM.
This (intra-domain) bidirectional sender&sender procedure can then be
applied between the QNE Edge (QNE Ingress and QNE Egress) nodes of
the RMD QoS signaling model. In the situation in which a security
association exists between the QNE Ingress and QNE Egress nodes (see
Figure 15), and the QNE Ingress node has the REQUIRED <Peak Data
Rate-1 (p)> values of the local RMD-QSPEC <TMOD-1> parameters for
both directions, i.e., QNE Ingress towards QNE Egress and QNE Egress
towards QNE Ingress, then the QNE Ingress MAY include both <Peak Data
Rate-1 (p)> values of the local RMD-QSPEC <TMOD-1> parameters (needed
for both directions) into the RMD-QSPEC within a RESERVE message. In
this way, the QNE Egress node is able to use the QoS parameters
needed for the "Egress towards Ingress" direction (QoS-2). The QNE
Egress is then able to create a RESERVE with the right QoS parameters
included in the QSPEC, i.e., RESERVE (QoS-2). Both directions of the
flows are bound by inserting <BOUND-SESSION-ID> objects at the QNE
Ingress and QNE Egress, which will be carried by bound end-to-end
RESERVE messages.
|------ RESERVE (QoS-1, QoS-2)----|
| V
| Interior/stateless QNEs
+---+ +---+
|------->|QNE|-----|QNE|------
| +---+ +---+ |
| V
+---+ +---+
|QNE| |QNE|
+---+ +---+
^ |
| | +---+ +---+ V
| |-------|QNE|-----|QNE|-----|
| +---+ +---+
Ingress/ Egress/
stateful QNE stateful QNE
|
<--------- RESERVE (QoS-2) -------|
Figure 16: The intra-domain bidirectional reservation scenario
in the RMD domain
Note that it is RECOMMENDED that the QNE implementations of RMD-QOSM
process the QoS-NSLP signaling messages with a higher priority than
data packets. This can be accomplished as described in Section 3.3.4
in [RFC5974] and the QoS-NSLP-RMF API [RFC5974].
A bidirectional reservation, within the RMD domain, is indicated by
the PHR <B> and PDR <B> flags, which are set in all messages. In
this case, two <BOUND-SESSION-ID> objects SHOULD be used.
When the QNE Edges maintain per-flow intra-domain QoS-NSLP
operational states, the end-to-end RESERVE message carries two BOUND-
SESSION-IDs. One BOUND-SESSION-ID carries the SESSION-ID of the
tunneled intra-domain (per-flow) session that is using a Binding_Code
with value set to code (Tunneled and end-to-end sessions). Another
BOUND-SESSION-ID carries the SESSION-ID of the bound bidirectional
end-to-end session. The Binding_Code associated with this BOUND-
SESSION-ID is set to code (Bidirectional sessions).
When the QNE Edges maintain aggregated intra-domain QoS-NSLP
operational states, the end-to-end RESERVE message carries two BOUND-
SESSION-IDs. One BOUND-SESSION-ID carries the SESSION-ID of the
tunneled aggregated intra-domain session that is using a Binding_Code
with value set to code (Aggregated sessions). Another BOUND-SESSION-
ID carries the SESSION-ID of the bound bidirectional end-to-end
session. The Binding_Code associated with this BOUND-SESSION-ID is
set to code (Bidirectional sessions).
The intra-domain and end-to-end QoS-NSLP operational states are
initiated/modified depending on the binding type (see Sections 4.3.1,
4.3.2, and 4.3.3).
If no security association exists between the QNE Ingress and QNE
Egress nodes, the bidirectional reservation for the sender&sender
scenario in the RMD domain SHOULD use the scenario specified in
[RFC5974] as "bidirectional reservation for sender&sender scenario".
This is because in this scenario, the RESERVE message sent from the
QNE Ingress to QNE Egress does not have to carry the QoS parameters
needed for the "Egress towards Ingress" direction (QoS-2).
In the following sections, it is considered that the QNE Edge nodes
are common for both upstream and downstream directions and therefore,
the two reservations/sessions can be bound at the QNE Edge nodes.
Furthermore, it is considered that a security association exists
between the QNE Ingress and QNE Egress nodes, and the QNE Ingress
node has the REQUIRED <Peak Data Rate-1 (p)> value of the local RMD-
QSPEC <TMOD-1> parameters for both directions, i.e., QNE Ingress
towards QNE Egress and QNE Egress towards QNE Ingress.
According to Section 3.2.3, it is specified that only the "per-flow
RMD reservation-based" in combination with the "severe congestion
handling by proportional data packet marking" scheme MUST be
implemented within one RMD domain. However, all RMD QNEs supporting
this specification MUST support the combination the "per-flow RMD
reservation-based" in combination with the "severe congestion
handling by proportional data packet marking" scheme. If the RMD
QNEs support more RMD-QOSM schemes, then the operator of that RMD
domain MUST preconfigure all the QNE Edge nodes within one domain
such that the <SCH> field included in the "PHR Container" (Section
4.1.2) and the "PDR Container" (Section 4.1.3) will always use the
same value, such that within one RMD domain, only one of the below
described RMD-QOSM schemes is used at a time.
All QNE nodes located within the RMD domain MUST read and interpret
the <SCH> field included in the "PHR Container" before processing all
the other <PHR Container> payload fields. Moreover, all QNE Edge
nodes located at the boarder of the RMD domain, MUST read and
interpret the <SCH> field included in the "PDR container" before
processing all the other <PDR Container> payload fields.
4.6.2.1. Successful and Unsuccessful Reservations
This section describes the operation of the RMD-QOSM where an RMD
Intra-domain bidirectional reservation operation, see Figure 16 and
Section 4.6.2, is either successfully or unsuccessfully accomplished.
The bidirectional successful reservation is similar to a combination
of two unidirectional successful reservations that are accomplished
in opposite directions, see Figure 17. The main differences of the
bidirectional successful reservation procedure with the combination
of two unidirectional successful reservations accomplished in
opposite directions are as follows. Note also that the intra-domain
and end-to-end QoS-NSLP operational states generated and maintained
by the end-to-end RESERVE messages contain, compared to the
unidirectional reservation scenario, a different BOUND-SESSION-ID
data structure (see Sections 4.3.1, 4.3.2, and 4.3.3). In this
scenario, the intra-domain RESERVE message sent by the QNE Ingress
node towards the QNE Egress node is denoted in Figure 17 as RESERVE
(RMD-QSPEC): "forward". The main differences between the intra-
domain RESERVE (RMD-QSPEC): "forward" message used for the
bidirectional successful reservation procedure and a RESERVE (RMD-
QSPEC) message used for the unidirectional successful reservation are
as follows (see the QoS-NSLP-RMF API described in [RFC5974]):
* the <RII> object MUST NOT be included in the message. This is
because no RESPONSE message is REQUIRED.
* the <B> bit of the PHR container indicates a bidirectional
reservation and it MUST be set to "1".
* the PDR container is also included in the RESERVE(RMD-QSPEC):
"forward" message. The value of the Parameter ID is "20", i.e.,
"PDR_Reservation_Request". Note that the response PDR container
sent by a QNE Egress to a QNE Ingress node is not carried by an
end-to-end RESPONSE message, but it is carried by an intra-domain
RESERVE message that is sent by the QNE Egress node towards the
QNE Ingress node (denoted in Figure 16 as RESERVE(RMD-QSPEC):
"reverse").
* the <B> PDR bit indicates a bidirectional reservation and is set
to "1".
* the <PDR Bandwidth> field specifies the requested bandwidth that
has to be used by the QNE Egress node to initiate another intra-
domain RESERVE message in the reverse direction.
The RESERVE(RMD-QSPEC): "reverse" message is initiated by the QNE
Egress node at the moment that the RESERVE(RMD-QSPEC): "forward"
message is successfully processed by the QNE Egress node.
The main differences between the RESERVE(RMD-QSPEC): "reverse"
message used for the bidirectional successful reservation procedure
and a RESERVE(RMD-QSPEC) message used for the unidirectional
successful reservation are as follows:
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
| | | | |
| | | | |
|RESERVE(RMD-QSPEC) | | |
|"forward" | | | |
| | RESERVE(RMD-QSPEC): | |
|--------------->| "forward" | | |
| |------------------------------>| |
| | | |------------->|
| | | | |
| | |RESERVE(RMD-QSPEC) |
| RESERVE(RMD-QSPEC) | "reverse" |<-------------|
| "reverse" | |<--------------| |
|<-------------------------------| | |
Figure 17: Intra-domain signaling operation for successful
bidirectional reservation
* the <RII> object is not included in the message. This is because
no RESPONSE message is REQUIRED;
* the value of the <Peak Data Rate-1 (p)> field of the local RMD-
QSPEC <TMOD-1> parameter is set equal to the value of the <PDR
Bandwidth> field included in the RESERVE(RMD-QSPEC): "forward"
message that triggered the generation of this RESERVE(RMD-QSPEC):
"reverse" message;
* the <B> bit of the PHR container indicates a bidirectional
reservation and is set to "1";
* the PDR container is included into the RESERVE(RMD-QSPEC):
"reverse" message. The value of the Parameter ID is "23", i.e.,
"PDR_Reservation_Report";
* the <B> PDR bit indicates a bidirectional reservation and is set
to "1".
Figures 18 and 19 show the flow diagrams used in the case of an
unsuccessful bidirectional reservation. In Figure 18, the QNE that
is not able to support the requested <Peak Data Rate-1 (p)> value of
local RMD-QSPEC <TMOD-1> is located in the direction QNE Ingress
towards QNE Egress. In Figure 19, the QNE that is not able to
support the requested <Peak Data Rate-1 (p)> value of local RMD-QSPEC
<TMOD-1> is located in the direction QNE Egress towards QNE Ingress.
The main differences between the bidirectional unsuccessful procedure
shown in Figure 18 and the bidirectional successful procedure are as
follows:
* the QNE node that is not able to reserve resources for a certain
request is located in the "forward" path, i.e., the path from the
QNE Ingress towards the QNE Egress.
* the QNE node that is not able to support the requested <Peak Data
Rate-1 (p)> value of local RMD-QSPEC <TMOD-1> MUST mark the <M>
bit, i.e., set to value "1", of the RESERVE(RMD-QSPEC): "forward".
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
| | | | |
|RESERVE(RMD-QSPEC): | | |
| "forward" | RESERVE(RMD-QSPEC): | |
|--------------->| "forward" | M RESERVE(RMD-QSPEC):
| |--------------------------->M "forward-M marked"
| | | M-------------->|
| | RESPONSE(PDR) M |
| | "forward - M marked"M |
|<------------------------------------------------------------|
|RESERVE(RMD-QSPEC, K=0) | M |
|"forward - T tear" | M |
|--------------->| | M |
| RESERVE(RMD-QSPEC, K=1) M |
| | "forward - T tear" M |
| |--------------------------->M |
| | RESERVE(RMD-QSPEC, K=1) |
| | "forward - T tear" |
| | M-------------->|
Figure 18: Intra-domain signaling operation for unsuccessful
bidirectional reservation (rejection on path
QNE(Ingress) towards QNE(Egress))
The operation for this type of unsuccessful bidirectional reservation
is similar to the operation for unsuccessful unidirectional
reservation, shown in Figure 9.
The main differences between the bidirectional unsuccessful procedure
shown in Figure 19 and the in bidirectional successful procedure are
as follows:
* the QNE node that is not able to reserve resources for a certain
request is located in the "reverse" path, i.e., the path from the
QNE Egress towards the QNE Ingress.
* the QNE node that is not able to support the requested <Peak Data
Rate-1 (p)> value of local RMD-QSPEC <TMOD-1> MUST mark the <M>
bit, i.e., set to value "1", the RESERVE(RMD-QSPEC): "reverse".
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
| | | | |
|RESERVE(RMD-QSPEC) | | |
|"forward" | RESERVE(RMD-QSPEC): | |
|--------------->| "forward" | RESERVE(RMD-QSPEC): |
| |-------------------------------->|"forward" |
| | RESERVE(RMD-QSPEC): |------------->|
| | "reverse" | | |
| | RESERVE(RMD-QSPEC) | |
| RESERVE(RMD-QSPEC): M "reverse" |<-------------|
| "reverse - M marked" M<---------------| |
|<--------------------------------M | |
| | M | |
|RESERVE(RMD-QSPEC, K=0): M | |
|"forward - T tear" M | |
|--------------->| RESERVE(RMD-QSPEC, K=0): | |
| | "forward - T tear" | |
| |-------------------------------->| |
| | M |------------->|
| | M RESERVE(RMD-QSPEC, K=0):
| | M "reverse - T tear" |
| | M |<-------------|
| M RESERVE(RMD-QSPEC, K=1) |
| | M "forward - T tear" |
| | M<---------------| |
| RESERVE(RMD-QSPEC, K=1)M | |
| "forward - T tear" M | |
|<--------------------------------M | |
Figure 19: Intra-domain signaling normal operation for unsuccessful
bidirectional reservation (rejection on path QNE(Egress)
towards QNE(Ingress)
* the QNE Ingress uses the information contained in the received PHR
and PDR containers of the RESERVE(RMD-QSPEC): "reverse" and
generates a tear intra-domain RESERVE(RMD-QSPEC): "forward - T
tear" message. This message carries a "PHR_Release_Request" and
"PDR_Release_Request" control information. This message is sent
to the QNE Egress node. The QNE Egress node uses the information
contained in the "PHR_Release_Request" and the
"PDR_Release_Request" control info containers to generate a
RESERVE(RMD-QSPEC): "reverse - T tear" message that is sent
towards the QNE Ingress node.
4.6.2.2. Refresh Reservations
This section describes the operation of the RMD-QOSM where an RMD
intra-domain bidirectional refresh reservation operation is
accomplished.
The refresh procedure in the case of an RMD reservation-based method
follows a scheme similar to the successful reservation procedure,
described in Section 4.6.2.1 and depicted in Figure 17, and how the
refresh process of the reserved resources is maintained and is
similar to the refresh process used for the intra-domain
unidirectional reservations (see Section 4.6.1.3).
Note that the RMD traffic class refresh periods used by the bound
bidirectional sessions MUST be equal in all QNE Edge and QNE Interior
nodes.
The main differences between the RESERVE(RMD-QSPEC): "forward"
message used for the bidirectional refresh procedure and a
RESERVE(RMD-QSPEC): "forward" message used for the bidirectional
successful reservation procedure are as follows:
* the value of the Parameter ID of the PHR container is "19", i.e.,
"PHR_Refresh_Update".
* the value of the Parameter ID of the PDR container is "21", i.e.,
"PDR_Refresh_Request".
The main differences between the RESERVE(RMD-QSPEC): "reverse"
message used for the bidirectional refresh procedure and the RESERVE
(RMD-QSPEC): "reverse" message used for the bidirectional successful
reservation procedure are as follows:
* the value of the Parameter ID of the PHR container is "19", i.e.,
"PHR_Refresh_Update".
* the value of the Parameter ID of the PDR container is "24", i.e.,
"PDR_Refresh_Report".
4.6.2.3. Modification of Aggregated Intra-Domain QoS-NSLP Operational
Reservation States
This section describes the operation of the RMD-QOSM where RMD intra-
domain bidirectional QoS-NSLP aggregated reservation states have to
be modified.
In the case when the QNE Edges maintain, for the RMD QoS Model, QoS-
NSLP aggregated reservation states and if such an aggregated
reservation has to be modified (see Section 4.3.1), then similar
procedures to Section 4.6.1.4 are applied. In particular:
* When the modification request requires an increase of the reserved
resources, the QNE Ingress node MUST include the corresponding
value into the <Peak Data Rate-1 (p)> field local RMD-QSPEC
<TMOD-1> parameter of the RMD-QOSM <QoS Desired>), which is sent
together with "PHR_Resource_Request" control information. If a
QNE Edge or QNE Interior node is not able to reserve the number of
requested resources, then the "PHR_Resource_Request" associated
with the local RMD-QSPEC <TMOD-1> parameter MUST be marked. In
this situation, the RMD-specific operation for unsuccessful
reservation will be applied (see Section 4.6.2.1). Note that the
value of the <PDR Bandwidth> parameter, which is sent within a
"PDR_Reservation_Request" container, represents the increase of
the reserved resources in the "reverse" direction.
* When the modification request requires a decrease of the reserved
resources, the QNE Ingress node MUST include this value into the
<Peak Data Rate-1 (p)> field of the local RMD-QSPEC <TMOD-1>
parameter of the RMD-QOSM <QoS Desired>). Subsequently, an RMD
release procedure SHOULD be accomplished (see Section 4.6.2.4).
Note that the value of the <PDR Bandwidth> parameter, which is
sent within a "PDR_Release_Request" container, represents the
decrease of the reserved resources in the "reverse" direction.
4.6.2.4. Release Procedure
This section describes the operation of the RMD-QOSM, where an RMD
intra-domain bidirectional reservation release operation is
accomplished. The message sequence diagram used in this procedure is
similar to the one used by the successful reservation procedures,
described in Section 4.6.2.1 and depicted in Figure 17. However, how
the release of the reservation is accomplished is similar to the RMD
release procedure used for the intra-domain unidirectional
reservations (see Section 4.6.1.5 and Figures 18 and 19).
The main differences between the RESERVE (RMD-QSPEC): "forward"
message used for the bidirectional release procedure and a RESERVE
(RMD-QSPEC): "forward" message used for the bidirectional successful
reservation procedure are as follows:
* the value of the Parameter ID of the PHR container is "18",
i.e."PHR_Release_Request";
* the value of the Parameter ID of the PDR container is "22", i.e.,
"PDR_Release_Request";
The main differences between the RESERVE (RMD-QSPEC): "reverse"
message used for the bidirectional release procedure and the RESERVE
(RMD-QSPEC): "reverse" message used for the bidirectional successful
reservation procedure are as follows:
* the value of the Parameter ID of the PHR container is "18", i.e.,
"PHR_Release_Request";
* the PDR container is not included in the RESERVE (RMD-QSPEC):
"reverse" message.
4.6.2.5. Severe Congestion Handling
This section describes the severe congestion handling operation used
in combination with RMD intra-domain bidirectional reservation
procedures. This severe congestion handling operation is similar to
the one described in Section 4.6.1.6.
4.6.2.5.1. Severe Congestion Handling by the RMD-QOSM Bidirectional
Refresh Procedure
This procedure is similar to the severe congestion handling procedure
described in Section 4.6.1.6.1. The difference is related to how the
refresh procedure is accomplished (see Section 4.6.2.2) and how the
flows are terminated (see Section 4.6.2.4).
4.6.2.5.2. Severe Congestion Handling by Proportional Data Packet
Marking
This section describes the severe congestion handling by proportional
data packet marking when this is combined with an RMD intra-domain
bidirectional reservation procedure. Note that the detection and
marking/re-marking functionality described in this section and used
by Interior nodes, applies to NSIS-aware but also to NSIS-unaware
nodes. This means however, that the "not NSIS-aware" Interior nodes
MUST be configured such that they can detect the congestion
situations and re-mark packets in the same way as the Interior "NSIS-
aware" nodes do.
This procedure is similar to the severe congestion handling procedure
described in Section 4.6.1.6.2. The main difference is related to
the location of the severe congested node, i.e., "forward" or
"reverse" path. Note that when a severe congestion situation occurs,
e.g., on a forward path, and flows are terminated to solve the severe
congestion in forward path, then the reserved bandwidth associated
with the terminated bidirectional flows will also be released.
Therefore, a careful selection of the flows that have to be
terminated SHOULD take place. An example of such a selection is
given in Appendix A.5.
Furthermore, a special case of this operation is associated with the
severe congestion situation occurring simultaneously on the forward
and reverse paths. An example of this operation is given in Appendix
A.6.
Simulation results associated with these procedures can be found in
[DiKa08].
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
user| | | | |
data| user | | | |
--->| data | user data | |user data |
|--------------->| | S |
| |--------------------------->S (#marked bytes)
| | | S-------------->|
| | | S(#unmarked bytes)
| | | S-------------->|Term
| | | S |flow?
| | NOTIFY (PDR) S |YES
|<------------------------------------------------------------|
|RESERVE(RMD-QSPEC) | S |
|"forward - T tear" | S |
|--------------->| | RESERVE(RMD-QSPEC):|
| |--------------------------->S"forward - T tear"
| | | S-------------->|
| | | RESERVE(RMD-QSPEC): |
| | | "reverse - T tear" |
| RESERVE(RMD-QSPEC): | |<--------------|
|"reverse - T tear" |<-------------S |
|<-----------------------------| S |
Figure 20: Intra-domain RMD severe congestion handling for
bidirectional reservation (congestion on path
QNE(Ingress) towards QNE(Egress))Figure 20 shows the scenario in which the severely congested node is
located in the "forward" path. The QNE Egress node has to generate
an end-to-end NOTIFY (PDR) message. In this way, the QNE Ingress
will be able to receive the (#marked and #unmarked) that were
measured by the QNE Egress node on the congested "forward" path.
Note that in this situation, it is assumed that the "reverse" path is
not congested.
This scenario is very similar to the severe congestion handling
scenario described in Section 4.6.1.6.2 and shown in Figure 14. The
difference is related to the release procedure, which is accomplished
in the same way as described in Section 4.6.2.4.
Figure 21 shows the scenario in which the severely congested node is
located in the "reverse" path. Note that in this situation, it is
assumed that the "forward" path is not congested. The main
difference between this scenario and the scenario shown in Figure 20
is that no end-to-end NOTIFY (PDR) message has to be generated by the
QNE Egress node.
This is because now the severe congestion occurs on the "reverse"
path and the QNE Ingress node receives the (#marked and #unmarked)
user data passing through the severely congested "reverse" path. The
QNE Ingress node will be able to calculate the number of flows that
have to be terminated or forwarded in a lower priority queue.
QNE(Ingress) QNE (int.) QNE (int.) QNE (int.) QNE(Egress)
NTLP stateful NTLP st.less NTLP st.less NTLP st.less NTLP stateful
user| | | | |
data| user | | | |
--->| data | user data | |user data |
|--------------->| | | |
| |--------------------------->|user data |user
| | | |-------------->|data
| | | | |--->
| | | user | |<---
| user data | | data |<--------------|
| (#marked bytes)| S<----------| |
|<--------------------------------S | |
| (#unmarked bytes) S | |
Term|<--------------------------------S | |
Flow? | S | |
YES |RESERVE(RMD-QSPEC): S | |
|"forward - T tear" s | |
|--------------->| RESERVE(RMD-QSPEC): | |
| | "forward - T tear" | |
| |--------------------------->| |
| | S |-------------->|
| | S RESERVE(RMD-QSPEC):
| | S "reverse - T tear" |
| RESERVE(RMD-QSPEC) S |<--------------|
| "reverse - T tear" S<----------| |
|<--------------------------------S | |
Figure 21: Intra-domain RMD severe congestion handling for
bidirectional reservation (congestion on path
QNE(Egress) towards QNE(Ingress))
For the flows that have to be terminated, a release procedure, see
Section 4.6.2.4, is initiated to release the reserved resources on
the "forward" and "reverse" paths.
4.6.2.6. Admission Control Using Congestion Notification Based on
Probing
This section describes the admission control scheme that uses the
congestion notification function based on probing when RMD intra-
domain bidirectional reservations are supported.
QNE(Ingress) Interior QNE (int.) Interior QNE(Egress)
NTLP stateful not NSIS aware not NSIS aware not NSIS aware NTLP stateful
user| | | | |
data| | | | |
--->| | user data | |user data |
|-------------------------------------------->S (#marked bytes)
| | | S-------------->|
| | | S(#unmarked bytes)
| | | S-------------->|
| | | S |
| | RESERVE(re-marked DSCP in GIST)):|
| | | S |
|-------------------------------------------->S |
| | | S-------------->|
| | | S |
| | RESPONSE(unsuccessful INFO-SPEC) |
|<------------------------------------------------------------|
| | | S |
Figure 22: Intra-domain RMD congestion notification based on
probing for bidirectional admission control (congestion
on path from QNE(Ingress) towards QNE(Egress))
This procedure is similar to the congestion notification for
admission control procedure described in Section 4.6.1.7. The main
difference is related to the location of the severe congested node,
i.e., "forward" path (i.e., path between QNE Ingress towards QNE
Egress) or "reverse" path (i.e., path between QNE Egress towards QNE
Ingress).
Figure 22 shows the scenario in which the severely congested node is
located in the "forward" path. The functionality of providing
admission control is the same as that described in Section 4.6.1.7,
Figure 15.
Figure 23 shows the scenario in which the congested node is located
in the "reverse" path. The probe RESERVE message sent in the
"forward" direction will not be affected by the severely congested
node, while the <DSCP> value in the IP header of any packet of the
"reverse" direction flow and also of the GIST message that carries
the probe RESERVE message sent in the "reverse" direction will be re-
marked by the congested node. The QNE Ingress is, in this way,
notified that a congestion occurred in the network, and therefore it
is able to refuse the new initiation of the reservation.
Note that the "not NSIS-aware" Interior nodes MUST be configured such
that they can detect the congestion/severe congestion situations and
re-mark packets in the same way as the Interior "NSIS-aware" nodes
do.
QNE(Ingress) Interior QNE (int.) Interior QNE(Egress)
NTLP stateful not NSIS aware NTLP st.less not NSIS aware NTLP stateful
user| | | | |
data| | | | |
--->| | user data | | |
|-------------------------------------------->|user data |user
| | | |-------------->|data
| | | | |--->
| | | | |user
| | | | |data
| | | | |<---
| S | user data | |
| S user data |<--------------------------|
| user data S<---------------| | |
|<---------------S | | |
| user data S | | |
| (#marked bytes)S | | |
|<---------------S | | |
| S RESERVE(unmarked DSCP in GIST)): |
| S | | |
|----------------S------------------------------------------->|
| S RESERVE(re-marked DSCP in GIST) |
| S<-------------------------------------------|
|<---------------S | | |
Figure 23: Intra-domain RMD congestion notification for
bidirectional admission control (congestion on path
QNE(Egress) towards QNE(Ingress))4.7. Handling of Additional Errors
During the QSPEC processing, additional errors MAY occur. The way in
which these additional errors are handled and notified is specified
in [RFC5975] and [RFC5974].
5. Security Considerations
5.1. Introduction
A design goal of the RMD-QOSM protocol is to be "lightweight" in
terms of the number of exchanged signaling message and the amount of
state established at involved signaling nodes (with and without
reduced-state operation). A side effect of this design decision is
to introduce second-class signaling nodes, namely QNE Interior nodes,
that are restricted in their ability to perform QoS signaling
actions. Only the QNE Ingress and the QNE Egress nodes are allowed
to initiate certain signaling messages.
Moreover, RMD focuses on an intra-domain deployment only.
The above description has the following implications for security:
1) QNE Ingress and QNE Egress nodes require more security and fault
protection than QNE Interior nodes because their uncontrolled
behavior has larger implications for the overall stability of the
network. QNE Ingress and QNE Egress nodes share a security
association and utilize GIST security for protection of their
signaling messages. Intra-domain signaling messages used for RMD
signaling do not use GIST security, and therefore they do not
store security associations.
2) The focus on intra-domain QoS signaling simplifies trust
management and reduces overall complexity. See Section 2 of RFC
4081 for a more detailed discussion about the complete set of
communication models available for end-to-end QoS signaling
protocols. The security of RMD-QOSM does not depend on Interior
nodes, and hence the cryptographic protection of intra-domain
messages via GIST is not utilized.
It is important to highlight that RMD always uses the message
exchange shown in Figure 24 even if there is no end-to-end signaling
session. If the RMD-QOSM is triggered based on an end-to-end (E2E)
signaling exchange, then the RESERVE message is created by a node
outside the RMD domain and will subsequently travel further (e.g., to
the data receiver). Such an exchange is shown in Figure 3. As such,
an evaluation of an RMD's security always has to be seen as a
combination of the two signaling sessions, (1) and (2) of Figure 24.
Note that for the E2E message, such as the RESERVE and the RESPONSE
message, a single "hop" refers to the communication between the QNE
Ingress and the QNE Egress since QNE Interior nodes do not
participate in the exchange.
QNE QNE QNE QNE
Ingress Interior Interior Egress
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| RESERVE (1) | | |
+--------------------------------------------->|
| RESERVE' (2) | | |
+-------------->| | |
| | RESERVE' | |
| +-------------->| |
| | | RESERVE' |
| | +------------->|
| | | RESPONSE' (2)|
|<---------------------------------------------+
| | | RESPONSE (1) |
|<---------------------------------------------+
Figure 24: RMD message exchange
Authorizing quality-of-service reservations is accomplished using the
Authentication, Authorization, and Accounting (AAA) framework and the
functionality is inherited from the underlying NSIS QoS NSLP, see
[RFC5974], and not described again in this document. As a technical
solution mechanism, the Diameter QoS application [RFC5866] may be
used. The end-to-end reservation request arriving at the Ingress
node will trigger the authorization procedure with the backend AAA
infrastructure. The end-to-end reservation is typically triggered by
a human interaction with a software application, such as a voice-
over-IP client when making a call. When authorization is successful
then no further user initiated QoS authorization check is expected to
be performed within the RMD domain for the intra-domain reservation.
5.2. Security Threats
In the RMD-QOSM, the Ingress node constructs both end-to-end and
intra-domain signaling messages based on the end-to-end message
initiated by the sender end node.
The Interior nodes within the RMD network ignore the end-to-end
signaling message, but they process, modify, and forward the intra-
domain signaling messages towards the Egress node. In the meantime,
resource reservation states are installed, modified, or deleted at
each Interior node along the data path according to the content of
each intra-domain signaling message. The Edge nodes of an RMD
network are critical components that require strong security
protection.
Therefore, they act as security gateways for incoming and outgoing
signaling messages. Moreover, a certain degree of trust has to be
placed into Interior nodes within the RMD-QOSM network, such that
these nodes can perform signaling message processing and take the
necessary actions.
With the RMD-QOSM, we assume that the Ingress and the Egress nodes
are not controlled by an adversary and the communication between the
Ingress and the Egress nodes is secured using standard GIST security,
(see Section 6 of [RFC5971]) mechanisms and experiences integrity,
replay, and confidentiality protection.
Note that this only affects messages directly addressed by these two
nodes and not any other message that needs to be processed by
intermediaries. The <SESSION-ID> object of the end-to-end
communication is visible, via GIST, to the Interior nodes. In order
to define the security threats that are associated with the RMD-QOSM,
we consider that an adversary that may be located inside the RMD
domain and could drop, delay, duplicate, inject, or modify signaling
packets.
Depending on the location of the adversary, we speak about an on-path
adversary or an off-path adversary, see also RFC 4081 [RFC4081].
5.2.1. On-Path Adversary
The on-path adversary is a node, which supports RMD-QOSM and is able
to observe RMD-QOSM signaling message exchanges.
1) Dropping signaling messages
An adversary could drop any signaling messages after receiving them.
This will cause a failure of reservation request for new sessions or
deletion of resource units (bandwidth) for ongoing sessions due to
states timeout.
It may trigger the Ingress node to retransmit the lost signaling
messages. In this scenario, the adversary drops selected signaling
messages, for example, intra-domain reserve messages. In the RMD-
QOSM, the retransmission mechanism can be provided at the Ingress
node to make sure that signaling messages can reach the Egress node.
However, the retransmissions triggered by the adversary dropping
messages may cause certain problems. Therefore, disabling the use of
retransmissions in the RMD-QOSM-aware network is recommended, see
also Section 4.6.1.1.1.
2) Delaying Signaling Messages
Any signaling message could be delayed by an adversary. For example,
if RESERVE' messages are delayed over the duration of the refresh
period, then the resource units (bandwidth) reserved along the nodes
for corresponding sessions will be removed. In this situation, the
Ingress node does not receive the RESPONSE within a certain period,
and considers that the signaling message has failed, which may cause
a retransmission of the "failed" message. The Egress node may
distinguish between the two messages, i.e., the delayed message and
the retransmitted message, and it could get a proper response.
However, Interior nodes suffer from this retransmission and they may
reserve twice the resource units (bandwidth) requested by the Ingress
node.
3) Replaying Signaling Messages
An adversary may want to replay signaling messages. It first stores
the received messages and decides when to replay these messages and
at what rate (packets per second).
When the RESERVE' message carried an <RII> object, the Egress will
reply with a RESPONSE' message towards the Ingress node. The Ingress
node can then detect replays by comparing the value of <RII> in the
RESPONSE' messages with the stored value.
4) Injecting Signaling Messages
Similar to the replay-attack scenario, the adversary may store a part
of the information carried by signaling messages, for example, the
<RSN> object. When the adversary injects signaling messages, it puts
the stored information together with its own generated parameters
(RMD-QSPEC <TMOD-1> parameter, <RII>, etc.) into the injected
messages and then sends them out. Interior nodes will process these
messages by default, reserve the requested resource units (bandwidth)
and pass them to downstream nodes.
It may happen that the resource units (bandwidth) on the Interior
nodes are exhausted if these injected messages consume too much
bandwidth.
5) Modifying Signaling Messages
On-path adversaries are capable of modifying any part of the
signaling message. For example, the adversary can modify the <M>,
<S>, and <O> parameters of the RMD-QSPEC messages. The Egress node
will then use the SESSION-ID and subsequently the <BOUND-SESSION-ID>
objects to refer to that flow to be terminated or set to lower
priority. It is also possible for the adversary to modify the RMD-
QSPEC <TMOD-1> parameter and/or <PHB Class> parameter, which could
cause a modification of an amount of the requested resource units
(bandwidth) changes.
5.2.2. Off-Path Adversary
In this case, the adversary is not located on-path and it does not
participate in the exchange of RMD-QOSM signaling messages, and
therefore is unable to eavesdrop signaling messages. Hence, the
adversary does not know valid <RII>s, <RSN>s, and <SESSION-ID>s.
Hence, the adversary has to generate new parameters and constructs
new signaling messages. Since Interior nodes operate in reduced-
state mode, injected signaling messages are treated as new once,
which causes Interior nodes to allocate additional reservation state.
5.3. Security Requirements
The following security requirements are set as goals for the intra-
domain communication, namely:
* Nodes, which are never supposed to participate in the NSIS
signaling exchange, must not interfere with QNE Interior nodes.
Off-path nodes (off-path with regard to the path taken by a
particular signaling message exchange) must not be able to
interfere with other on-path signaling nodes.
* The actions allowed by a QNE Interior node should be minimal
(i.e., only those specified by the RMD-QOSM). For example, only
the QNE Ingress and the QNE Egress nodes are allowed to initiate
certain signaling messages. QNE Interior nodes are, for example,
allowed to modify certain signaling message payloads.
Note that the term "interfere" refers to all sorts of security
threats, such as denial-of-service, spoofing, replay, signaling
message injection, etc.
5.4. Security Mechanisms
An important security mechanism that was built into RMD-QOSM was the
ability to tie the end-to-end RESERVE and the RESERVE' messages
together using the BOUND-SESSION-ID and to allow the Ingress node to
match the RESERVE' with the RESPONSE' by using the <RII>. These
mechanisms enable the Edge nodes to detect unexpected signaling
messages.
We assume that the RESERVE/RESPONSE is sent with hop-by-hop channel
security provided by GIST and protected between the QNE Ingress and
the QNE Egress. GIST security mechanisms MUST be used to offer
authentication, integrity, and replay protection. Furthermore,
encryption MUST be used to prevent an adversary located along the
path of the RESERVE message from learning information about the
session that can later be used to inject a RESERVE' message.
The following messages need to be mapped to each other to make sure
that the occurrence of one message is not without the other:
a) the RESERVE and the RESERVE' relate to each other at the QNE
Egress; and
b) the RESPONSE and the RESERVE relate to each other at the QNE
Ingress; and
c) the RESERVE' and the RESPONSE' relate to each other. The <RII> is
carried in the RESERVE' message and the RESPONSE' message that is
generated by the QNE Egress node contains the same <RII> as the
RESERVE'. The <RII> can be used by the QNE Ingress to match the
RESERVE' with the RESPONSE'. The QNE Egress is able to determine
whether the RESERVE' was created by the QNE Ingress node since the
intra-domain session, which sent the RESERVE', is bound to an end-
to-end session via the <BOUND-SESSION-ID> value included in the
intra-domain QoS-NSLP operational state maintained at the QNE
Egress.
The RESERVE and the RESERVE' message are tied together using the
BOUND-SESSION-ID(s) maintained by the intra-domain and end-to-end
QoS-NSLP operational states maintained at the QNE Edges (see Sections
4.3.1, 4.3.2, and 4.3.3). Hence, there cannot be a RESERVE' without
a corresponding RESERVE. The SESSION-ID can fulfill this purpose
quite well if the aim is to provide protection against off-path
adversaries that do not see the SESSION-ID carried in the RESERVE and
the RESERVE' messages.
If, however, the path changes (due to rerouting or due to mobility),
then an adversary could inject RESERVE' messages (with a previously
seen SESSION-ID) and could potentially cause harm.
An off-path adversary can, of course, create RESERVE' messages that
cause intermediate nodes to create some state (and cause other
actions) but the message would finally hit the QNE Egress node. The
QNE Egress node would then be able to determine that there is
something going wrong and generate an error message.
The severe congestion handling can be triggered by intermediate nodes
(unlike other messages). In many cases, however, intermediate nodes
experiencing congestion use refresh messages modify the <S> and <O>
parameters of the message. These messages are still initiated by the
QNE Ingress node and carry the SESSION-ID. The QNE Egress node will
use the SESSION-ID and subsequently the BOUND-SESSION-ID, maintained
by the intra-domain QoS-NSLP operational state, to refer to a flow
that might be terminated. The aspect of intermediate nodes
initiating messages for severe congestion handling is for further
study.
During the refresh procedure, a RESERVE' creates a RESPONSE', see
Figure 25. The <RII> is carried in the RESERVE' message and the
RESPONSE' message that is generated by the QNE Egress node contains
the same <RII> as the RESERVE'.
The <RII> can be used by the QNE Ingress to match the RESERVE' with
the RESPONSE'.
A further aspect is marking of data traffic. Data packets can be
modified by an intermediary without any relationship to a signaling
session (and a SESSION-ID). The problem appears if an off-path
adversary injects spoofed data packets.
QNE Ingress QNE Interior QNE Interior QNE Egress
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| REFRESH RESERVE' | |
+-------------->| REFRESH RESERVE' |
| (+RII) +-------------->| REFRESH RESERVE'
| | (+RII) +------------->|
| | | (+RII) |
| | | |
| | | REFRESH |
| | | RESPONSE'|
|<---------------------------------------------+
| | | (+RII) |
Figure 25: RMD REFRESH message exchange
The adversary thereby needs to spoof data packets that relate to the
flow identifier of an existing end-to-end reservation that SHOULD be
terminated. Therefore, the question arises how an off-path adversary
SHOULD create a data packet that matches an existing flow identifier
(if a 5-tuple is used). Hence, this might not turn out to be simple
for an adversary unless we assume the previously mentioned
mobility/rerouting case where the path through the network changes
and the set of nodes that are along a path changes over time.
6. IANA Considerations
This section defines additional codepoint assignments in the QSPEC
Parameter ID registry, in accordance with BCP 26 [RFC5226].
6.1. Assignment of QSPEC Parameter IDs
This document specifies the following QSPEC containers in the QSPEC
Parameter ID registry created in [RFC5975]:
<PHR_Resource_Request> (Section 4.1.2 above, ID=17)
<PHR_Release_Request> (Section 4.1.2 above, ID=18)
<PHR_Refresh_Update> (Section 4.1.2 above, ID=19)
<PDR_Reservation_Request> (Section 4.1.3 above, ID=20)
<PDR_Refresh_Request> (Section 4.1.3 above, ID=21)
<PDR_Release_Request> (Section 4.1.3 above, ID=22)
<PDR_Reservation_Report> (Section 4.1.3 above, ID=23)
<PDR_Refresh_Report> (Section 4.1.3 above, ID=24)
<PDR_Release_Report> (Section 4.1.3 above, ID=25)
<PDR_Congestion_Report> (Section 4.1.3 above, ID=26)
7. Acknowledgments
The authors express their acknowledgement to people who have worked
on the RMD concept: Z. Turanyi, R. Szabo, G. Pongracz, A. Marquetant,
O. Pop, V. Rexhepi, G. Heijenk, D. Partain, M. Jacobsson, S.
Oosthoek, P. Wallentin, P. Goering, A. Stienstra, M. de Kogel, M.
Zoumaro-Djayoon, M. Swanink, R. Klaver G. Stokkink, J. W. van
Houwelingen, D. Dimitrova, T. Sealy, H. Chang, and J. de Waal.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signaling Transport", RFC 5971, October 2010.
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS
Signaling Layer Protocol (NSLP) for Quality-of-Service
Signaling", RFC 5974, October 2010.
[RFC5975] Ash, G., Bader, A., Kappler C., and D. Oran, "QSPEC
Template for the Quality-of-Service NSIS Signaling Layer
Protocol (NSLP)", RFC 5975, October 2010.
8.2. Informative References
[AdCa03] Adler, M., Cai, J.-Y., Shapiro, J. K., Towsley, D.,
"Estimation of congestion price using probabilistic packet
marking", Proc. IEEE INFOCOM, pp. 2068-2078, 2003.
[AnHa06] Lachlan L. H. Andrew and Stephen V. Hanly, "The Estimation
Error of Adaptive Deterministic Packet Marking", 44th
Annual Allerton Conference on Communication, Control and
Computing, 2006.
[AtLi01] Athuraliya, S., Li, V. H., Low, S. H., Yin, Q., "REM:
active queue management", IEEE Network, vol. 15, pp.
48-53, May/June 2001.
[Chan07] H. Chang, "Security support in RMD-QOSM", Masters thesis,
University of Twente, 2007.
[CsTa05] Csaszar, A., Takacs, A., Szabo, R., Henk, T., "Resilient
Reduced-State Resource Reservation", Journal of
Communication and Networks, Vol. 7, No. 4, December 2005.
[DiKa08] Dimitrova, D., Karagiannis, G., de Boer, P.-T., "Severe
congestion handling approaches in NSIS RMD domains with
bi-directional reservations", Journal of Computer
Communications, Elsevier, vol. 31, pp. 3153-3162, 2008.
[JaSh97] Jamin, S., Shenker, S., Danzig, P., "Comparison of
Measurement-based Admission Control Algorithms for
Controlled-Load Service", Proceedings IEEE Infocom '97,
Kobe, Japan, April 1997.
[GrTs03] Grossglauser, M., Tse, D.N.C, "A Time-Scale Decomposition
Approach to Measurement-Based Admission Control",
IEEE/ACM Transactions on Networking, Vol. 11, No. 4,
August 2003.
[Part94] C. Partridge, Gigabit Networking, Addison Wesley
Publishers (1994).
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview", RFC
1633, June 1994.
[RFC2215] Shenker, S. and J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements", RFC
2215, September 1997.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[RFC2638] Nichols, K., Jacobson, V., and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet",
RFC 2638, July 1999.
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B., Wroclawski, J., and E.
Felstaine, "A Framework for Integrated Services Operation
over Diffserv Networks", RFC 2998, November 2000.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC
3175, September 2001.
[RFC3726] Brunner, M., Ed., "Requirements for Signaling Protocols",
RFC 3726, April 2004.
[RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth
Constraints Model for Diffserv-aware MPLS Traffic
Engineering", RFC 4125, June 2005.
[RFC4127] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints
Model for Diffserv-aware MPLS Traffic Engineering", RFC
4127, June 2005.
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for
Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5866] Sun, D., Ed., McCann, P., Tschofenig, H., Tsou, T., Doria,
A., and G. Zorn, Ed., "Diameter Quality-of-Service
Application", RFC 5866, May 2010.
[RFC5978] Manner, J., Bless, R., Loughney, J., and E. Davies, Ed.,
"Using and Extending the NSIS Protocol Family", RFC 5978,
October 2010.
[RMD1] Westberg, L., et al., "Resource Management in Diffserv
(RMD): A Functionality and Performance Behavior Overview",
IFIP PfHSN 2002.
[RMD2] G. Karagiannis, et al., "RMD - a lightweight application
of NSIS" Networks 2004, Vienna, Austria.
[RMD3] Marquetant A., Pop O., Szabo R., Dinnyes G., Turanyi Z.,
"Novel Enhancements to Load Control - A Soft-State,
Lightweight Admission Control Protocol", Proc. of the 2nd
Int. Workshop on Quality of Future Internet Services,
Coimbra, Portugal, Sept 24-26, 2001, pp. 82-96.
[RMD4] A. Csaszar et al., "Severe congestion handling with
resource management in diffserv on demand", Networking
2002.
[TaCh99] P. P. Tang, T-Y Charles Tai, "Network Traffic
Characterization Using Token Bucket Model", IEEE Infocom
1999, The Conference on Computer Communications, no. 1,
March 1999, pp. 51-62.
[ThCo04] Thommes, R. W., Coates, M. J., "Deterministic packet
marking for congestion packet estimation" Proc. IEEE
Infocom, 2004.
