Subject: RE: [NSIS] proposals related to NSIS WG draft

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 9 Apr 2002 12:46:39 +0200

Hi Sven

I agree with you, on introducing the term "QoS Receiver", however,
I would very much appreciate if 
the sentence:
 "QoS Receiver: Network entity, located at the edge of or inside 
  a QoS ..."

is changed into:

""QoS Receiver: Network entity, located at an end host, an edge of 
  or inside a QoS ..."

Best Regards,
Georgios

-----Original Message-----
From: Sven Van den Bosch [mailto:[email-masked]]
Sent: dinsdag 19 maart 2002 23:44
To: [email-masked]
Subject: [NSIS] proposals related to NSIS WG draft

Hi all,

As an outcome of this morning's NSIS meeting, we propose the following 
detailed additions to the WG draft.

1. Terminology

- QoS Controller: Network entity responsible for interpreting and 
implementing the signaled QoS in the network. Failure to do so implies an 
admission control decision. It can only be triggered by another NSIS entity 
of the same instance (a QoS Initiator or another QoS Controller).

- QoS Receiver: Network entity, located at the edge of or inside a QoS 
domain, responsible for terminating an instance of an NSIS protocol. It has 
the additional functionality that it may initiate an acknowledgment towards 
the QI and that it may trigger another NSIS entity (QoS Initiator or QoS 
Controller of another instance of the NSIS protocol)

- QoS Initiator: Network entity, located at the edge of or inside a QoS 
domain, responsible for initiating an instance of an NSIS QoS signaling 
protocol. It may be triggered by the application layer, by the termination 
of a local QoS signaling mechanism (possibly another instance of NSIS 
signaling) or by a QoS Controller of another of a client instance of an NSIS 
protocol. It provides a mapping between the QoS parameters contained in the 
trigger and the QoS parameters in the instance of the NSIS protocol for 
which is serves as QoS Initiator.

2. Use cases/scenarios: 2 are available from the draft-buchli (sections 4.1 
and 4.2)

3. Requirements

* New requirements
- in section MUST support priority
The priority of a flow is essentially decoupled from its QoS requirements. 
Therefore the protocol MUST support priority. As a consequence, it MUST 
support preemption of traffic flows in case of congestion or failure. A 
preemption action MAY trigger an attempt to resetup the request by means of 
another instance of an NSIS signaling protocol.

- in section 5.3: MAY support grouping of microflows (possibly only for 
feedback)
As a consequence of the optimization for the interactive multimedia 
services, the signaling should allow one unique request for several micro 
flows having the same origination and destination IP addresses. This is 
usually the case for multimedia SIP calls where the voice and video micro 
flows follow the same path. This grouping of requests allows optimization of 
the QoS processing. Note that this may be detrimental for the call setup 
time. The use of grouping for microflows may be restricted to teardown 
and/or notification messages when call setup time is a concern.

- in section 5.5: Protocol content
The per-flow QoS requests are mapped onto the bandwidth pipe, which is 
specified by an SLS. These pipes may provide statistical guarantees such as 
delay and packet loss bounds (depending on the QoS class). In order to 
invoke per-flow QoS services the only parameter needed is a required rate, a 
means to identify the data path (mapping on SLS) and eventually a 
reservation identifier.

1) Microflow/reservation description
The signaling should allow the request to describe the microflow whose QoS 
would be guaranteed by giving at least the source and destination IP 
addresses of the media flow. In case the QC is stateful (per microflow) 
there may be a need to include a unique reservation identifier (e.g. QI 
identifier+counter) such that in case of e.g. a tear down message the 
reservation can be easily identified in the QC.

2) Traffic descriptor
The required peak rate must be signaled. Optionally the traffic parameters 
may be expressed in terms of token bucket parameters (similar to the TSpec 
in RSVP).

- in section 5.10: Interworking with provisioning

* Requirements for which to change priority or formulation
- MUST support signalling to entities outside the data path (reformulation)

- MUST NOT be adversely impacted by mobility aspects (applicable for 
end-to-end)
A QoS controller in an end-to-end instance of an NSIS protocol MUST NOT be 
adversely affected by mobility issues. Any mobility scenario should be 
tackled by other uses of an NSIS protocol and is outside the realm of an 
end-to-end application of the NSIS protocol.

_________________________________________________________________
Download MSN Explorer gratis van http://explorer.msn.nl/intl.asp.

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

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

---

From: [email-masked]
Date: Wed, 10 Apr 2002 23:53:00 +0200

Hi Georgios,

I am not against it, although I think the wording although covers the case
of an end-host. Let's change it for clarity though.

Sven.

"Georgios Karagiannis (ELN)" <[email-masked]> on
09/04/2002 12:46:39

  To:          "'Sven Van den Bosch'"                         
               <[email-masked]>, [email-masked]   
                                                              
  cc:          (bcc: Sven VAN DEN BOSCH/BE/ALCATEL)           

  Subject      RE: [NSIS] proposals related to NSIS WG draft  
  :                                                           

Hi Sven

is changed into:

Best Regards,
Georgios

-----Original Message-----
From: Sven Van den Bosch [mailto:[email-masked]]
Sent: dinsdag 19 maart 2002 23:44
To: [email-masked]
Subject: [NSIS] proposals related to NSIS WG draft

Hi all,

1. Terminology

signaling) or by a QoS Controller of another of a client instance of an
NSIS

3. Requirements

* New requirements

flows follow the same path. This grouping of requests allows optimization
of

invoke per-flow QoS services the only parameter needed is a required rate,
a

2) Traffic descriptor