Thank you. I believe that wraps up all of my concerns. Your very
prompt and energetic assistance on this is appreciated.
Yours,
Joel
Georgios Karagiannis wrote:
Hi Joel
I have another alternative!
Will the following text satisfy your concerns?
* However, all RMD QNEs supporting this specification MUST support the
combination the "per flow RMD reservation based" in combination with
"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 pre-configure all the QNE edge nodes within one domain
such that the <SCH> field included in the "PHR container", see Section
4.1.2 and the "PDR Container", see section 4.1.3, will use always the
same value, such that within one RMD domain only one of the below
described RMD-QOSM schemes is used at a time.
Best regards,
Georgios
-----Original Message-----
From: Georgios Karagiannis [mailto:[email protected]]
Sent: donderdag 18 maart 2010 16:01
To: 'Joel M. Halpern'
Cc: 'Mary Barnes'; [email protected];
[email protected]; [email protected];
'Magnus Westerlun'; [email protected]; 'Lars Eggert'
Subject: RE: [Gen-art] LC review: draft-ietf-nsis-rmd-16.txt
Hi Joel
Thank you very much!
Will it be acceptable if we will modify the following text from:
* However, only the "per flow RMD reservation based" in
combination with "severe congestion handling by proportional
data packet marking"
scheme MUST be implemented within one RMD domain.
If more RMD-QOSM schemes are implemented within one RMD
domain then the operator of that RMD domain MUST
pre-configure all the QNE edge nodes within one domain such
that the <SCH> field included in the "PHR container", see
Section 4.1.2 and the "PDR Container", see section 4.1.3,
will use always the same value, such that within one RMD
domain only one of the below described RMD-QOSM schemes can
be used at a time.
INTO:
* However, the "per flow RMD reservation based" in
combination with "severe congestion handling by proportional
data packet marking"
scheme MUST be implemented and supported within one RMD domain.
If more RMD-QOSM schemes are implemented and supported within
one RMD domain then the operator of that RMD domain MUST
pre-configure all the QNE edge nodes within one domain such
that the <SCH> field included in the "PHR container", see
Section 4.1.2 and the "PDR Container", see section 4.1.3,
will use always the same value, such that within one RMD
domain only one of the below described RMD-QOSM schemes is
used at a time.
Best regards,
Georgios
-----Original Message-----
From: Joel M. Halpern [mailto:[email protected]]
Sent: donderdag 18 maart 2010 15:45
To: Georgios Karagiannis
Cc: Mary Barnes; [email protected];
[email protected]; [email protected]; Magnus
Westerlun; [email protected]; Lars Eggert
Subject: Re: [Gen-art] LC review: draft-ietf-nsis-rmd-16.txt
My concern with 3.2.3 is not with what a network operator MUST
implement
in their domain. I understand that the primary
requirement there is
that they MUST choose one.
My concern is what the device implementor / vendor MUST
support. Our
normal practice is to mandate, even for intra-domain
operation, that
there be a single choice that all implementations (devices
or software
stacks, build by vendors or open source or ...) MUST
support. Thus,
if you take two random implementations, there exists a way to plug
them together such that it is at least reasonable to expect
interoperation.
This is not something the network designer can do, since
his choices
are inherently limited by what the tools he has support.
Yours,
Joel
Georgios Karagiannis wrote:
Hi Joel
Thanks for the quick reply and for sending the new comments!
We will try to resolve them, please see below:
On 3/17/2010, "Joel M. Halpern" <[email protected]> wrote:
Most of these changes look very good, and address the
issue I was raising.
I have one request for further wordsmithing, one issue
that I must
have been unclear on because the correction, while useful,
does not
seem to address what I was trying to raises, and one
question for clarification.
Georgios: Thank you!
The wordsmithing:
The proposed clarification of severe congestion reads:
Severe congestion: Is the congestion situation on a
particular link
within the RMD domain where a significant increase in its real
packet queue situation occurs, when due to a link failure
re-routed
traffic
I would like to ask, assuming that it matches your
intention, that
the "when due to a link failure" become "such as when due
to a link failure".
The reason I ask this is not so much that there are other causes
(there
are) as to put the emphasis on the congestion, rather than
on the failure.
Georgios: We will provide this cahnge!
I was apparently insufficiently clear about my
interoperability concern.
You have written very nice text about what the operator must do.
However, the concern is that with 6 schemes documents,
implementors
may not choose to support all the schemes.
One solution is to mandate that all implementations MUST
support all
schemes.
The more typical approach in the IETF is to pick one
scheme (usually
the
default) and require that all implementations must support that.
You can argue that operators will know what they want, and
will buy
devices that will interoperate using the scheme that the
operator wants.
Based on experience, this is a bad bet.
Georgios: In order to solve this issue, I would like to
propose the
following change in the modification that text we seny previously:
In Section 3.2.3 the folowing modification is proposed:
Chnage from:
However, all schemes MUST be implemented within one RMD
domain. The
operator of an RMD domain MUST pre-configure all the QNE
edge nodes
within one domain such that the <SCH> field included in the "PHR
container", see Section 4.1.2 and the "PDR Container",
see section
4.1.3, will use always the same value, such that within one
RMD domain
only one of the below described RMD-QOSM schemes can be
used at a time.
INTO:
* However, only the "per flow RMD reservation based" in
combination
with "severe congestion handling by proportional data
packet marking"
scheme MUST be implemented within one RMD domain. If
more RMD-QOSM
schemes are implemented within one RMD domain then the
operator of that
RMD domain MUST pre-configure all the QNE edge nodes
within one domain
such that the <SCH> field included in the "PHR
container", see Section
4.1.2 and the "PDR Container", see section 4.1.3, will
use always the
same value, such that within one RMD domain only one of
the below
described RMD-QOSM schemes can be used at a time."
The clarification is about the interaction of extant flows and
reservations in the measurement scheme. The problem is
definitely
ameliorated by the lack of refresh messages.
However, if I understand the document properly, if the bandwidth
changes, a new message will be send with only the new
reservation
amount. But the observation (measurement) will actually
include the
existing traffic. Thus, the existing traffic seems to be
double-counted.
Georgios: I think that you are refering to Section 4.6.1.4. "RMD
modification of aggregated reservations". Please note that this
section applies only to the "per aggregate RMD reservation
based" scheme.
In order to clarify this issue we will include the
following sentence
on the bullets that are explaining the "per aggregate RMD
reservation
based" scheme:
"This scheme can be considered to be a reservation-based
scheme, since
the RMD interior nodes are reduced-state nodes, i.e., they do not
store NTLP/GIST states but they do store per PHB-aggregated
QoS-NSLP
reservation states."
In section 4.6.1.4 we will want to inlcude the following sentence:
"This modification scheme applies only to the following
two RMD-QOSM
schemes:
* "per aggregate RMD reservation based" in combination with
"severe congestion handling by the RMD-QOSM refresh
procedure"
* "per aggregate RMD reservation based" in combination with
"severe congestion handling by proportional data
packet marking"
Best regards,
Georgios
Thank you for your efforts,
And I hope and expect we can come to closure on these
remaining items.
Joel
Georgios Karagiannis wrote:
Dear Joel
Thank you very much for the excellent review!
Below we tried to resolve all your comments/issues!
It will be great if you could inform us if you are
satisfied with
these solutions!
On 3/13/2010, "Joel M. Halpern" <[email protected]> wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call
comments you may receive.
Document: draft-ietf-nsis-rmd-16.txt
RMD-QOSM - The Resource Management in Diffserv QOS Model
Reviewer: Joel M. Halpern
Review Date: 13-Mar-2010
IETF LC End Date: 22-Mar-2010
IESG Telechat date: N/A
Summary: This document is not ready for publication as
an Experimental RFC.
Clarity Issue:
The document makes repeated use of the term Severe
congestion. It
seems inevitable that a somewhat fuzzy definition will
be used for
that, and I would not have concern about such fuzziness.
However,
the definition used in the document, in section 2,
presumably with
the understanding and agreement of the working group, is
"congestion that occurs when a node or link fails and
the traffic
is rerouter through another node or link." This
property (being
caused by node or link failure) has nothing to do with
the severity
of the congestion. The text goes on to talk about
this type of
congestion not be addressable via admission control.
It is possible that the document means severe
congestion (in the
more conventional sense) with the added caveat that it
is brought
about by failure. But that is not what the definition
says. (If
that is indeed the intent, then clarifying the definition will
suffice to resolve this
issue.)
Also, as a lesser matter, there are systems which do address /
prevent element failures from causing severe
congestion by using
admission control, so the claim in the definition that
it can not
be addressed by admission control is at best misleading. It
requires very different behaviors than RMD,so are
presumably inapplicable to this situation.
Georgios: We would like to change the severe congestion
definition
given in Section 2 as follows,
From:
Severe congestion: is a congestion that occurs when a
node or link
fails and the traffic is rerouter through another node
or link. If no
measures are taken than the node or the link can
become severely
congested and all traffic passing through the node
or link will
severely degrade in QoS. This type of congestion
cannot be solved
using admission control mechanisms.
INTO:
Severe congestion: Is the congestion situation on a
particular link
within the RMD domain where a significant increase in its real
packet queue situation occurs, when due to a link failure
re-routed
traffic has to be supported by this particular link. A
failure in a
communication path, e.g., a router or a link causes the routing
algorithms to adapt to this failure by changing the routing
decisions to reflect changes in the topology and traffic
volume. As
a result, the re-routed traffic will follow a new path
and link,
which may result in severely overloaded nodes and links
as they need
for a long time to support more traffic than they are able to.
Major issues:
Section 3.2.3 on applicability seems to state that
although there
are Multiple RMD-QOSM schemes, none are mandatory to
implement.
And that a domain must all use one scheme. I am not sure if
"scheme: here refers to this document as distinct from
some other
document, or refers to the variations (such as reduced
state, and
two varieties of stateless) on interior node behavior. If, as
seems to be the case since the following text defines 5
schemes, it
is referring to the interior behavior choices, it would
seem that
there needs to be a mandatory-to-implement scheme in
order for this
document to promote interoperability rather than
fragmentation of the network.
Georgios: We will do the following modifications in order
to solve
this
issue:
In Section 3.2.3 we will replace the existing paragraph that is
associated with the above issue with the following paragraph:
------------------
A very important consideration on using RMD-QOSM is that
within one
RMD domain only one of the following RMD-QOSM schemes can
be used at
a time. Thus a RMD router can never process and use two
different
RMD-QOSM signaling schemes at the same time.
However, all schemes MUST be implemented within one RMD
domain. The
operator of an RMD domain MUST pre-configure all the QNE
edge nodes
within one domain such that the <SCH> field included in
the "PHR
container", see Section 4.1.2 and the "PDR Container",
see section
4.1.3, will use always the same value, such that within one RMD
domain only one of the below described RMD-QOSM schemes
can be used
at a time.
----------------
Moreover, in Sections 4.1.2 and 4.1.3 we will include the new
description of the <SCH> filed that will be included on
the most
right 3 bits of the second 32 bit payload word. The
following text will be used:
------------------
In Section 4.1.2:
--------------------
<SCH>: 3-bit. The <SCH> value that is used to
specify which of
the 6 RMD scenarios, see Section 3.2.3, MUST be used
within the RMD domain.
The operator of an RMD domain MUST pre-configure all
the QNE edge
nodes within one domain such that the <SCH> field
included in the
"PHR container", will use always the same value, such
that within
one RMD domain only one of the below described RMD-QOSM
schemes can
be used at a time. All the QNE interior nodes MUST
interpret this
field before processing any other PHR container payload
fields. The
currently defined <SCH> values are:
o 0: RMD-QOSM scheme MUST be: "per flow
congestion notification
based on probing";
o 1: RMD-QOSM scheme MUST be: "per flow RMD NSIS
measurement
based
admission control",
o 2: RMD-QOSM scheme MUST be: "per flow RMD
reservation based"
in
combination with "severe congestion handling
by the RMD-QOSM
refresh procedure";
o 3 : RMD-QOSM scheme MUST be: "per flow RMD
reservation based"
in
combination with "severe congestion handling
by proportional
data packet marking"
o 4: RMD-QOSM scheme MUST be: "per aggregate RMD
reservation
based"
in combination with "severe congestion
handling by the RMD-
QOSM refresh procedure"
o 5: RMD-QOSM scheme MUST be: "per aggregate RMD
reservation
based"
in combination with "severe congestion handling by
proportional data packet marking"
o 6 - 7: reserved
The default value of the <SCH> field SHOULD be set to
the value
equal to 3.
------------
In Section 4.1.3:
--------------
<SCH>:
3-bit. The <SCH> value that is used to specify which of
the 6 RMD
scenarios, see Section 3.2.3, MUST be used within the
RMD domain.
The operator of an RMD domain MUST pre-configure all
the QNE edge
nodes within one domain such that the <SCH> field
included in the
"PDR container", will use always the same value, such
that within
one RMD domain only one of the below described RMD-QOSM
schemes can
be used at a time. All the QNE interior nodes MUST
interpret this
field before processing any other "PDR container"
payload fields.
The currently defined <SCH> values are:
o 0: RMD-QOSM scheme MUST be: "per flow
congestion notification
based on probing";
o 1: RMD-QOSM scheme MUST be: "per flow RMD NSIS
measurement
based
admission control",
o 2: RMD-QOSM scheme MUST be: "per flow RMD
reservation based"
in
combination with "severe congestion handling
by the RMD-QOSM
refresh procedure";
o 3 : RMD-QOSM scheme MUST be: "per flow RMD
reservation based"
in
combination with "severe congestion handling
by proportional
data packet marking"
o 4: RMD-QOSM scheme MUST be: "per aggregate RMD
reservation
based"
in combination with "severe congestion
handling by the RMD-
QOSM refresh procedure"
o 5: RMD-QOSM scheme MUST be: "per aggregate RMD
reservation
based"
in combination with "severe congestion handling by
proportional data packet marking"
o 6 - 7: reserved
The default value of the <SCH> field SHOULD be set to
the value
equal to 3.
In this day and age, it seems surprising that
the protocol
specifies that the interior messages are to be sent with no
security. The IETF is actively working to improve the
security of
intra-domain and inter-domain routing, so this decision seems
wrong. (Even for an
experiment.) (Section 4.4, 4th bullet.) At the very
least, some
explanation of this choice is necessary.
Georgios: You are right, the text needs to be
clarified. What we
meant is that RMD-QOSM relies mainly on the security and
reliability
support that is provided by the bound end-to-end session,
which is
running between the boundaries of the RMD domain (i.e.,
the RMD-QOSM
QNE edges) and the security provided by the D-mode.
We would want to change the specific bullet into:
* When the QNE Ingress needs to send an intra-domain RESERVE
message that is not an initial RESERVE, then the
QoS-NSLP sends
this message by including in the GIST API
SendMessage primitive such
attributes that the usage of the Datagram Mode is
implied, e.g.,
Unreliable attribute. Furthermore the Local policy
attribute is set
such that GIST sends the intra-domain RESERVE
message in a Q-mode
even if there is a routing state at the QNE Ingress.
In this way the
GIST functionality uses its local policy to send the
intra-domain
RESERVE message by piggybacking it on a GIST DATA
message and sending
it in Q- mode even if there is a routing state for
this session. The
intra-domain RESERVE message is piggybacked on the
GIST DATA message
that is forwarded and processed by the QNE Interior
nodes up to
the QNE
Egress.
------------------
Moreover, we will include the following paragraph at the
introductory part of Section 4.4.
------------------
"RMD-QOSM relies on the security and
reliability support that is provided by the bound
end-to-end session,
which is running between the boundaries of the RMD
domain (i.e., the
RMD-QOSM QNE edges), and the security provided by
the D-mode."
-------------------
The text in section 4.1.2 states that the 8 bit
overload % field
contains a real value. However, I could not find a
description of
the encoding by which a real value between (between 0 and 1?)
should be encoded in the message.
Georgios: Agree that the description of this filed is not
clear and
too many bits are used to represent this type of
overload, while not needed.
Therefore, we will do the following changes:
In Section 4.1.2 we will do the following change.
Change from:
<Overload %>:
8 bits In case of severe congestion the level of overload is
indicated by the Overload %. Overload % is the
percentage of the
measured PHB bit rate that is above the bit rate rate
used to detect
a severe congestion. Overload % SHOULD be higher than
0 if S bit is
set. If overload in a node is greater than the
overload in a previous
node then Overload % SHOULD be updated. For more
details see Section
4.6.1.6.1. Note that this field represents a real parameter.
INTO:
<Overload>:
1 bit. This field is used during the severe congestion
handling scheme
that is using the RMD-QOSM refresh procedure. This bit
is set when an
overload on a QNE interior node is detected and when
this field is
carried by the "PHR_Refresh_Update" container. <Overload>
SHOULD be set to"1" if the <S> bit is set. For more
details see
Section 4.6.1.6.1.
in Section 4.1.3 a similar change for this parameter will
be applied:
<Overload>:
1 bit. This field is used during the severe congestion
handling scheme
that is using the RMD-QOSM refresh procedure. This bit
is set when an
overload on a QNE interior node is detected and when
this field is
carried by the ""PDR_Congestion_Report" container. <Overload>
SHOULD be set to"1" if the <S> bit is set. For more
details see
Section
4.6.1.6.1.
-------------
This change on the <Overlaod> filed will be worked out in
the rest
of the text.
Minor issues:
The measurement based admission control mechanism used
here looks
remarkably similar to the classical RSVP Predicative
service. Both
of these are based on the assumption that current measured
characteristics are an indicator of future load. It is
not at all
apparent that there is any such relationship. It
seems that the
text ought to include some indication as to what the basis of
suggesting this be used is, and why it is thought to be
meaningful.
Even if the argument is "it is worth trying", it seems worth
stating that, and stating why it is thought that it will
work now.
Georgios: You are right about the fact that the
measurement based
admission control scheme can only support a predictive service.
We would like to change the following paragraph in
section 3.1 from:
The measurement-based algorithm continuously measures
traffic levels
and the actual available resources, and admits flows
whose resource
needs are within what is available at the time of
the request.
INTO:
The measurement-based algorithm continuously measures
traffic levels
and the actual available resources, and admits flows
whose resource
needs are within what is available at the time of the
request. The
measurement based algorithm is used to support a
predictive service
where the service commitment is somewhat less reliable than the
service that can be supported by the reservation based
method. A
main assumption that is taken by such measurement based
admission
control mechanisms is that the aggregated PHB traffic passing
through an RMD interior node is high and therefore, current
measurement characteristics are considered to be an
indicator of future load.
It would probably be helpful to explain why it
is necessary or
desirable to use two different RESERVE messages across
the same
domain, traversing the same set of devices, with different but
closely related information. (particularly in light of the
comments about reducing load on intermediate devices.)
Georgios: You are right we will try to clarify this as follows:
In Section 3.1 we would like to change the following text from:
"The basic RMD-QOSM/QoS-NSLP signaling is shown in
Figure 3. The
signalling scenarios are accomplished using the
QoS-NSLP processing
rules defined in [QoS-NSLP], in combination with the
RMF triggers
sent via the QoS-NSLP-RMF API described in [QoS-NSLP].
A RESERVE
message is created by a QNI with an Initiator QSpec
describing the
reservation and forwarded along the path towards the QNR."
INTO:
"The basic RMD-QOSM/QoS-NSLP signaling is shown in
Figure 3. The
signalling scenarios are accomplished using the
QoS-NSLP processing
rules defined in [QoS-NSLP], in combination with the
RMF triggers
sent via the QoS-NSLP-RMF API described in [QoS-NSLP].
Due to the fact that within the RMD domain a different
QoS model can
be supported than the end-to-end QoS model applied at
the edges of the
RMD domain, the RMD interior node reduced state
reservations can be
updated independently of the per-flow end-to-end
reservations, see
Section 4.7 of [QoS-NSLP]. Therefore, two different RESERVE
messages are
used within the RMD domain. One RESERVE message that
is associated with
the per flow end-to-end reservations and is used by
the edges of the
RMD domain and one that is associated with the reduced state
reservations within the RMD domain."
The applicability section states that this mechanism
can only be
used with the EF DSCP. Is it further the case that it
can only be
used for traffic which consistently uses a stable amount of
bandwidth (per reservation)? One of the difficulties with the
style of reservation based on measurement of load is
that the end
pointing requesting the measurement must be aware of
whether the
measurement data includes the flow being considered for
admission.
Otherwise, large flows can cause significant confusion.
With very
stable flows, as long as the measurements are not
requested too often, this is achievable.
Otherwise, it is not at all clear to this reader how the
proposed
mechanism would work (particularly when refreshing a
reservation).
Continuing this line of questioning, the mechanism for
modification seems to send the new bandwidth through the
stateless
intra-domain routers. Since they are stateless, those
routers do
now know what the old reservation was. And the measurements
presumably include traffic under the old reservation.
if these are
added together, significant double-counting woudl seem
to occur.
(This is listed as minor on the premise that the protocol
presumably actually works, and therefore the problem is one of
reader comprehension, rather than more serious
technical issues.
Georgios: You are right that the descriptions are not
clear. Please
note that with the measurement based scheme the requested peak
bandwidth of a flow is carried by the admission control
request. The
admission decision is considered as positive if the currently
carried traffic, as characterized by the measured
statistics, plus
the requested resources for the new flow exceeds the
system capacity
with a probability smaller than a value alpha. Otherwise, the
admission decision is negative. It is important to
emphasize that
due to the fact that the interior nodes are stateless,
they do not
store information of previous admission control requests.
This could
lead to a situation where the admission control accuracy is
decreased when multiple simultaneous flows (sharing a common
interior node) are requesting admission control
simultaneously. By
applying measuring techniques, see e.g., [JaSh97],
[GrTs03], which
are using current and past information on NSIS sessions that
requested resources from an NSIS aware interior node, the
decrease in admission control accuracy can be limited.
Moreover, the RMD measurement based schemes described in this
document do not use any refresh procedures, since these
approaches
are used in stateless nodes, see Section 4.6.1.3.
In order to clarify the text we would like to do the following.
The abstract description of the measurement based
admission control
mechanism given in Section 3.1 will be enhanced as follows:
We will add the following paragraph in Section 3.1:
"It is important to emphasize that the RMD measurement
based schemes
described in this document do not use any refresh
procedures, since
these approaches are used in stateless nodes, see
Section 4.6.1.3.
With the measurement based scheme the requested peak
bandwidth of a
flow is carried by the admission control request. The admission
decision is considered as positive if the currently
carried traffic,
as characterized by the measured statistics, plus the requested
resources for the new flow exceeds the system capacity with a
probability smaller than a value alpha. Otherwise, the
admission
decision is negative. It is important to emphasize that
due to the
fact that the interior nodes are stateless, they do not store
information of previous admission control requests. This
could lead
to a situation where the admission control accuracy is
decreased
when multiple simultaneous flows (sharing a common
interior node)
are requesting admission control simultaneously. By applying
measuring techniques, see e.g., [JaSh97], [GrTs03], which
are using
current and past information on NSIS sessions that requested
resources from an NSIS aware interior node, the decrease
in admission control accuracy can be limited."
I was not able to understand the purpose or use of the
K bit. I
may have missed it in the dense text. Assuming there is an
explanation, a pointer at the point where the bit is
defined to the
text which explains its use would be a very good idea.
Georgios: You are right. The use of the <K> bit is described in
Section 4.6.1.5.2.
The description of the <K> bit will be changed as follows:
<K>: 1 bit. When set to "1" it indicates that the
resources/bandwidth
carried by a tearing RESERVE MUST NOT be released and the
resources/bandwidth carried by a non tearing RESERVE
MUST NOT be
reserved/refreshed. For more details see Section 4.6.1.5.2.
Best regards,
Georgios
Yours,
Joel M. Halpern
Nits/editorial comments:
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
