Subject: [NSIS] Receiver Initiated Reservations on QoS NSLP

From: David Palma <[email-masked]>
Date: Tue, 24 Oct 2006 11:18:48 +0000

Hi all,

I have a doubt on the QoS NSLP draft. On the receiver initiated
reservations it seems that the QUERY message should go downstream,
RESERVE upstream and finally a downstream RESPONSE.

>From my point of view it would make sense to initiate the process with
an upstream QUERY (since GIST supports upstream associations) followed
by a downstream RESERVE and upstream RESPONSE. This approach would allow
to have clearer state machine for RESERVE and RESPONSE messages since
they would be processed as any sender initiated reservation. Besides
this the downstream path would always be the same as the data flow path
and this could be helpful on  scenarios with different upstream and
downstream bandwidth.

Does this idea make sense?

Thank you for your time,

Best Regards,
David Palma

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Roland Bless <[email-masked]>
Date: Wed, 25 Oct 2006 15:17:22 +0200

Hi David,

> RESERVE upstream and finally a downstream RESPONSE.

Yep. The QUERY message only serves the purpose of finding the
_correct_ path from sender to receiver in downstream direction.
This "GIST-fixed" path can then be used to send a RESERVE in upstream
direction, ensuring that this RESERVE traverses the correct nodes.

> an upstream QUERY (since GIST supports upstream associations) followed
Quote from sec. 5.8.1.3.:
You might have missed the "health warning" note that an upstream
Query is not really a reliable method to determine the *real* path:

   In general, it is not possible to determine the hop-by-hop route
   upstream because of asymmetric routing.  However, in particular
   cases, the upstream peer can be discovered with a high degree of
   confidence, for example:

   o  The upstream GIST peer is 1 IP hop away, and can be reached by
      tracing back through the interface on which the flow arrives.

   o  The upstream peer is a border router of a single-homed (stub)
      network.

...

 The rationale for this is that the downstream
   Query is in general a more reliable way to install state, since it
   directly probes the routing infrastructure along the flow path,
   whereas use of the upstream Query depends on the correctness of the
   Querying node's understanding of the topology.

> Does this idea make sense?

No, but you may find my earlier proposal a little bit more
along your lines of thought (namely having the RESERVE always
going from sender to receiver, i.e. downstream):
http://www1.ietf.org/mail-archive/web/nsis/current/msg05182.html
(the diagram was messed up somehow...)
or even older (Sep. 2004)
http://www1.ietf.org/mail-archive/web/nsis/current/msg04367.html

For your convenience I'll repeat it here:
-----------------------------------------------------------------------
QNI (receiver)    QNE           QNE          QNR (sender)
  | RI-RESERVE (direct or bypassing)          |
  |------------------------------------------>|
  |                                 RESERVE   |
  |                    RESERVE   |<---------- |1)
  |   RESERVE       |<-----------|            |
2)|<----------------|            |            |
  |RESPONSE         |            |            |
  |---------------->| RESPONSE   |            |
  |                 |----------->| RESPONSE   |
  |                 |            |----------->|
1) RESERVE carries additional an RSN of the RI-RESERVE
2) RESERVE with additional RSN of RI-RESERVE is
   interpreted as RESPONSE to RI-RESERVE

This alternative would simply require a forwarding a RI-RESERVE request
from the receiver to the sender and one additional RSN object. It would
not require any state installation during this 1st way. The sender would
then initiate (or not if local policy forbids it) a normal RESERVE
towards the receiver, except that this RESERVE would carry additionally
a reference to the RI-RESERVE. When the receiver gets the RESERVE it
considers it as response to its RI-RESERVE and sends the normal RESPONSE
back. This would also require a 3-way exchange, but no path state
installation with a query or some other
mechanism beforehand. Furthermore, bi-directional reservations could
also be performed (if not in parallel) by piggybacking an RI-RESERVE to
a normal RESERVE.

One could argue that the RI-RESERVE should rather be sent by some
application level signaling protocol.
However, in my opinion it would be nice to have such a capability inside
the NSLP itself, because it does not
depend on the capability of the app level signaling
(if there is such at all) to do so...
-------------------------------------------------------------------
Regards,
 Roland

---

From: "Roy, Radhika R." <[email-masked]>
Date: Wed, 25 Oct 2006 09:46:37 -0400

Ronald:

Just a little clarification on your statement, "... the app level signaling
(if there is such at all) to do so..."

Yes, the application does have those capabilities if IETF looks into the beauty and simplicity of the application level QOS signaling.

ITU-T's H.323 application does have a standard to use RSVP QOS signaling messages using guaranteed, controlled, and best-effort QOS classes DIRECTLY.

In the same token, the much more versatile NSIS QOS signaling standard messages can also be used directly by the applications like H.323 and SIP. However, SIP/SDP needs a little more works to perform this. If the NSIS, SIP, and SDP standards would have been under the same WG, this work of standardization for application-level QOS signaling could be done more smoothly and in an integrated way.

Now all knowledge of QOS signaling from the application layer to the network layer and below is segmented in different WGs and experts. It has created a significant problem to solve the QOS signaling problems either from the end-to-end basis and/or from the application layer to the lower layers.

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roland Bless
Sent: Wednesday, October 25, 2006 9:17 AM
To: David Palma
Cc: [email-masked]; Luís Cordeiro
Subject: Re: [NSIS] Receiver Initiated Reservations on QoS NSLP

Hi David,

---

From: Roland Bless <[email-masked]>
Date: Wed, 25 Oct 2006 16:03:36 +0200

Hi,

> Ronald:

no , I'm Roland.

> Just a little clarification on your statement, "... the app level
> signaling (if there is such at all) to do so..."
> 
> Yes, the application does have those capabilities if IETF looks into
> the beauty and simplicity of the application level QOS signaling.

Application Level Signaling is rather an end-to-end signaling
(e.g. if you consider a direct SIP call for example) than infrastructure
signaling.
NSIS QoS Signaling is about signaling to the network infrastructure
elements because you want network resources. Requesting QoS from the
application level only may work, but is limited to the particular
application (or its signaling protocol).

> ITU-T's H.323 application does have a standard to use RSVP QOS
> signaling messages using guaranteed, controlled, and best-effort QOS
> classes DIRECTLY.
> 
> In the same token, the much more versatile NSIS QOS signaling
> standard messages can also be used directly by the applications like
> H.323 and SIP. However, SIP/SDP needs a little more works to perform
> this. If the NSIS, SIP, and SDP standards would have been under the
> same WG, this work of standardization for application-level QOS
> signaling could be done more smoothly and in an integrated way.

But using NSIS is more general and modular, because
I also want QoS for non-SIP-based applications which is something that
A-IMS also wants to achieve (if I understood correctly). So I'm in favor
of doing it separately from SIP, because there are so many applications
which may do different things than using SIP...(remember innovation is
[easier] at the edge).

> Now all knowledge of QOS signaling from the application layer to the
> network layer and below is segmented in different WGs and experts. It
> has created a significant problem to solve the QOS signaling problems
> either from the end-to-end basis and/or from the application layer to
> the lower layers.

QoS mapping is required and not easy, but its solvable...

Regards,
 Roland

> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Roland Bless Sent:
> Wednesday, October 25, 2006 9:17 AM To: David Palma Cc:
> [email-masked]; Luís Cordeiro Subject: Re: [NSIS] Receiver Initiated
> Reservations on QoS NSLP
> 
> Hi David,
> 
> application level signaling protocol. However, in my opinion it would
> be nice to have such a capability inside the NSLP itself, because it
> does not depend on the capability of the app level signaling (if
> there is such at all) to do so... 
> Regards, Roland

-- 
Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless
Institut für Telematik, Universität Karlsruhe (TH), Germany
Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358
Tel.: +49 721 608-6413 Fax: +49 721 608-6789

---

From: "Roy, Radhika R." <[email-masked]>
Date: Wed, 25 Oct 2006 11:31:42 -0400

Roland:

Sorry about misspelling earlier.

Inline [RRR].

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, October 25, 2006 10:04 AM
To: Roy, Radhika R.
Cc: David Palma; [email-masked]; Luís Cordeiro
Subject: Re: [NSIS] Receiver Initiated Reservations on QoS NSLP

Hi,

no , I'm Roland.

[RRR] See above.

[RRR] NSIS does have the upper layer that will be used by the applications. The application layer QOS signaling is the standard applications like SIP/SDP how to signal NSIS QOS signaling messages to express theirs needs. There is a little work from standardization purpose. NSIS may not do this work, but SIP, SIPPING, and MMUSIC WG need to this work in collaboration with NSIS.

But using NSIS is more general and modular, because
I also want QoS for non-SIP-based applications which is something that
A-IMS also wants to achieve (if I understood correctly). 

[RRR] Sure, but those applications MUST have standards like SIP/SDP. All standard applications will have their own application QOS signaling messages, and these signaling messages must have a standard to use NSIS signaling messages. (An analogy can be is this: Many networks from 3GPP, cable, IP, ATM, FR, etc. can use DiffServ code points.)

So I'm in favor of doing it separately from SIP, because there are so many applications which may do different things than using SIP...(remember innovation is [easier] at the edge).

[RRR] It is not about SIP or non-SIP applications. It is about all applications like SIP/SDP that have been standardized in the IETF. All applications MUST have standards how to use NSIS signaling messages using "standard" code points/interfaces/messages DIRECTLY.

[RRR] If there are non-IETF standard applications like IMS, CableLabs, and other, they may do the same (that's not IETF's primary headache).

[RRR] It depends what you are looking into. For example, it is easy to map the application layer QOS signaling messages of a given individual application to NSIS QOS signaling messages (an analogy is given - mapping of H.323 signaling messages to RSVP/IntServ signaling messages).

[RRR] The above is also true for the lower network QOS when one needs to map network QOS signaling/model and the NSIS QOS signaling messages (e.g., DiffServ <-> NSIS, RSVP <-> NSIS, IntServ <-> NSIS, DSTE <-> NSIS, Y.1541 <-> NSIS, 3GPP <-> NSIS). It is a straight forward to do so (as can be seen all individual QOSM drafts prepared so far). It is NOT a rocket science.

[RRR] Then what is the problem? The very SERIOUS Problems come when one needs to do "Interworking" between the different network layer QOS (It must be noted that there is no need to "interwork" between two different application layer QOS signaling messages as both ends will use the same application).

[RRR] In intewroking of the network layer QOS, there are couple of layers where the problems reside. To sort them out, we have to analyze as follows:

[RRR] a. Generic non-value-based non-implementation-specific QOS signaling schemes: where QOS signaling messages are being standardized. All we need to map between them and NSIS QOS signaling messages. For example, IETF's DiffServ, RSVP, and IntServ are the standards which qualify them. In those cases, the Interworking between these IETF standard QOS schemes using NSIS signaling messages are straight forward, and they easily interwork. So, it is not a problem because each of these protocols is based on the well-defined QOS properties (not hard-coded some values).

[RRR] b. Non-Generic Value-based Implementation-specific QOS signaling schemes: where only some values of a group of QOS parameters have been defined. Any violation of any value of any QOS parameter will be treated as non-compliant. They have SERIOUS problems for INTERWORKING because of the following: First, they do not have any "QOS signaling messages." Second, they do NOT define general QOS characteristics based on which one can understand what properties they have other than some hard-coded values. Third, they want to use NSIS QOS signaling messages DIRECTLY using those hard-coded values of group-based QOS parameters as they do have one. For example, Y.1541, 3GPP/Y.1541 QOSM, and DSTE are of those categories. More importantly, these value-based implementation-specific QOS schemes are NOT for standardization. These can be used for ONLY implementation something like SLA agreements. For example, OSP is designed to offer Interworking between different value-based implementations among different implementers.

Regards,
 Roland