Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions

From: [email-masked]
Date: Fri, 15 Mar 2002 08:58:36 +0100

Hello Gabor et al,,

As the general agreement seems that NSIS be limited to the bearer level
only, and in order to avoid confusion in the future, I propose to add a new
point to the section "4.3 Exclusions", that could be phrased as follows:

"Specific methods, protocols, and ways to express QoS information in the
Application/Session level are not considered (e.g., SDP, SIP, RTSP, etc.);
therefore when the NSIS protocol is used to reserve resources with QoS
constraints, it is assumed that the application/session level has already
been able to determine/negotiate the QoS requirements between the
end-users, for each requested bearer.
The specification of any extensions needed to signal QoS information via
application level protocols (e.g. SDP(ng)), and the mapping on NSIS
information are considered outside of the scope of NSIS working group, as
this work is in the direct scope of other IETF working groups (e.g.
MMUSIC)."

Comments ?
Best regards
Juan Carlos

---------------------- Forwarded by Juan-Carlos ROJAS/FR/ALCATEL on
15/03/2002 08:38 ---------------------------

Juan-Carlos ROJAS
12/03/2002 13:58

To:   [email-masked] (Gabor Fodor), [email-masked],
      "[email-masked]'" <[email-masked]>
cc:   [email-masked]
Subject:  RE: [NSIS] section 3.5 in nsis-req-00.txt  (Document link: Listes
      Discussion)

Hi Gabor,

OK, if this is a general agreement in the NSIS wg, it is not my intention
to go against the world.
It would be preferable if this is clearly written in the requirements
document: see e.g. section "4.3 Exclusions", the point 2 could be extended
in this way.

Best regards

     Juan Carlos

[email-masked] (Gabor Fodor) on 11/03/2002 18:08:23

To:   Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL
cc:   [email-masked]
Subject:  RE: [NSIS] section 3.5 in nsis-req-00.txt

Hi Juan-Carlos,

my answer to your question :

> question I'm raising is more "Is in the context of NSIS to define ways of
> expressing QoS requirements also at the session level ?".

would be "no", becuase in my understanding this WG focuses
on IP level QoS signaling mechanisms.

However, I agree with you when you say that :

> ... what will be agreed at the session/application
> layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for
> resource reservation complying with the QoS requirements. The most

Therefore, it is important that we carefully select the bearer level
paramaters ("define the bearer service(s)"), when we reach that discussion.
To emphasize this, we could consider to add a requirement (at the
level of those in Section 5.1) that NSIS signaling should support
a wide range of media streams, or something more elaborated.

/Gabor

> From [email-masked] Mon Mar 11 17:17:52 2002
> From: [email-masked]
> Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt
> To: [email-masked] (Gabor Fodor)
> Cc: [email-masked]
> Date: Mon, 11 Mar 2002 17:17:03 +0100
> X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8
|June 18, 2001) at
>  03/11/2002 17:17:04
> MIME-Version: 1.0
> Content-Transfer-Encoding: 8bit
> X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org
id LAA27058
> X-Mailman-Version: 1.0
> List-Id: Next Steps in Signaling <nsis.ietf.org>
> X-BeenThere: [email-masked]
>
>
> Hi Gabor,
>
> No major problem with this.
> You are right when saying that "There are already mechanisms that allow
> coordination between the session layer and the bearer (IP) layer";
however,
> there is no standardized way to exchange and negotiate QoS information at
> session level (we are currently proposing SDP extensions for that).
> I'm not asking to define "how parties make service agreements", but the
> question I'm raising is more "Is in the context of NSIS to define ways of
> expressing QoS requirements also at the session level ?".
> The main purpose is that what will be agreed at the session/application
> layer (e.g. SIP, RTSP, etc.) will be used to ask the bearer level for
> resource reservation complying with the QoS requirements. The most
> straight-forward will be the translation, the less error-prone will be
the
> implementation.
> And for sure, at the end, the QoS information should allow a mapping on
> different QoS technologies.
>
> Otherwise, I fully agree with you, we are currently specifying
> requirements, the definition work will come later.
>
> Best regards
> Juan Carlos
>
>
>
>
>
> [email-masked] (Gabor Fodor) on 11/03/2002 16:28:09
>
> To:   Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL
> cc:   [email-masked]
> Subject:  RE: [NSIS] section 3.5 in nsis-req-00.txt
>
>
> Juan-Carlos,
>
> in this respect I fully support one view that was expressed
> in a previous mail on this list, which formulated a requirement
> that the [NSIS QoS signaling] architecture must be completely
> agnostic as to how parties make service agreements. That is,
> the service advertisement shoud be handled at the application
> level.
>
> There are already mechanisms that allow coordination between the
> session layer and the bearer (IP) layer, including the notion
> of pre-conditions in SIP.
>
> However, I view it as an important requirement that
> "the information exchanged over the signaling protocol
> must be in such detail and quantity
> that it is useful for various QoS technologies"
> [draft-brunner-nsis..., Section 5.1].
>
> Of course, this "level of detail and quantity"
> should support various applications without requiring from
> application programmers that complex and qualitative parameters
> should be set. Therefore, we have a challange to define such
> paramater set(s) at the IP level that help various underlying
> QoS technologies to provide QoS and are "application programmer
> friendly". Such sets allow parties to configure their QoS parameters
> after negotiating a service at the application layer.
> (This definition work is of course left after the requirements
> discussion.)
>
> /Gabor
>
>
>
>
>
> > From [email-masked] Mon Mar 11 15:51:42 2002
> > From: [email-masked]
> > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt
> > To: "Geib, Ruediger" <[email-masked]>
> > Cc: [email-masked], "Geib, Ruediger"
> <[email-masked]>,
> >         [email-masked]
> > Date: Mon, 11 Mar 2002 15:50:50 +0100
> > X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8
> |June 18, 2001) at
> >  03/11/2002 15:50:51
> > MIME-Version: 1.0
> > Content-Transfer-Encoding: 8bit
> > X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org
> id JAA21126
> > X-Mailman-Version: 1.0
> > List-Id: Next Steps in Signaling <nsis.ietf.org>
> > X-BeenThere: [email-masked]
> >
> >
> > Hi all,
> >
> > There is a general agreement that NSIS should not define services
> > (applications); I fully support this view.
> > However, a QoS signalling protocol should provide the necessary
> mechanisms
> > to allow applications to define, exchange, negotiate QoS
characteristics.
> > This seems to me a fondamental question: if we agree that in the NGN
> > providers will sell services and not only some transport capacity, then
> the
> > QoS story cannot be considered anymore as only a matter of bearer
> handling,
> > you need to have a global view including the session layer (e.g.
SIP/SDP)
> > and the applications.
> > Next, it should be up to the involved actors to define a common
agreement
> > on the service that is to be provided.
> > My feeling is that this is fully inline with the IETF philosophy:
define
> > basic mechanisms, and next, allow the actors to build services on top
of
> > basic mechanisms.
> >
> > Best regards
> > Juan Carlos
> >
> >
> >
> >
> >
> > "Geib, Ruediger" <[email-masked]>@ietf.org on 08/03/2002
> > 11:40:03
> >
> > Sent by:  [email-masked]
> >
> >
> > To:   [email-masked], "Geib, Ruediger"
> >       <[email-masked]>
> > cc:   [email-masked]
> > Subject:  RE: [NSIS] section 3.5 in nsis-req-00.txt
> >
> >
> > Hi John,
> >
> > I'd appreciate if NSIS takes care of the issue (a MAY is fine for now).
> The
> > first requirement may be reworded to clarify that NSIS does not define
> the
> > service (I'm neither a native speaker nor a legal expert, so I'm not
sure
> > whether your suggestion does so).
> > NSIS then MAY be the IETF WG to collect, check and administrate the
> service
> > description coded according to NSIS rules? If you don't know the answer
> we
> > could have a look on the RTP spec's. Also they support a mechanism
> offering
> > a signaling framework which may be (and is) filled by later individual
> > specifications.
> >
> > Regards, Rüdiger
> >
> >
> > > > NSIS must support a flexible service definition not
> > > > restricting contents and meaning of individual service
> > > > descriptions. Services may either be private or public.
> > >
> > > Would these requirements be OK?
> > >
> > >    NSIS SHOULD support application level service descriptions.
> > >
> > >    NSIS MAY consider support for service descriptions developed
> > >    by other SDOs.
> > >
> > > This would mean that applications could do the service negotiations,
> > > and pass this info to NSIS.
> > >
> > > It also means that NSIS could support ITU-T Y.1541, or 3GPP's QoS
> > > classes.
> > >
> > > John
> > >
> >
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
> >
> >
> >
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
>
>
>
>
>
> _______________________________________________
> 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] (Gabor Fodor)
Date: Fri, 15 Mar 2002 10:10:28 +0100 (MET)

Hi Juan-Carlos,

I agree that some additional text in the Exclusion
section can actually help to make the scope even more clear.
Also, while I agree with the main point of your proposed text,
we would probably need to iterate a bit more on excatly how 
this text could be best formulated. 

So please see my comments inline :

> From [email-masked] Fri Mar 15 08:58:45 2002
> Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions
> Date: Fri, 15 Mar 2002 08:58:36 +0100
> 
> Hello Gabor et al,,
> 
OK

> end-users, for each requested bearer.
This text actually assumes that the parties use application/session
level signaling to negotiate QoS prior to NSIS signaling. 
While this is probably the typical case, 
NSIS should not be restricted to this model. 

> this work is in the direct scope of other IETF working groups (e.g.
Yes, I agree, but let me add the following.

I agree that the mapping from e.g. the SDP parameters to NSIS bearer parameters
are out of scope, but when determining the bearer classes and their associated
paramaters, it seems necessary that we take into account what information is
signalled at the SIP/SDP level. 

For instance, some SDP descriptors may contain explicit information about 
the voice codec (and its associated mime description) that is used 
in the session. This information can be useful to carry as a "local domain
information" [Brunner draft 5.5, bullet 2)] in a wireless scenario, 
where the QI and the wireless link manager does not sit in the same node.
There may be other such cases which we will need to discuss at a later stage
(after the requirements doc).

> Juan Carlos

Regards /Gabor

---

From: [email-masked]
Date: Fri, 15 Mar 2002 10:45:42 +0100

Hi Gabor,

Thank you for your comments.
See my comments to your comments inline, between <jc> and </jc> brackets

Best regards
Juan Carlos

[email-masked] (Gabor Fodor) on 15/03/2002 10:10:28

To:   Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL
cc:   [email-masked], [email-masked], [email-masked]
Subject:  RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions

Hi Juan-Carlos,

OK

<jc>End-parties will always agree on what to do, before doing it; but
"application/session level" shall not be restricted to SIP; the application
can be contacted just using your web browser and http, or even using a
telephone call in case of long duration pipes reservation for e.g.
corporate networks.
Maybe this can be re-phrased as follows "..., it is assumed that end
parties previously determined/negotiated the QoS expectations using methods
that are out of the scope of the NSIS WG" </jc>

I agree that the mapping from e.g. the SDP parameters to NSIS bearer
parameters
are out of scope, but when determining the bearer classes and their
associated
paramaters, it seems necessary that we take into account what information
is
signalled at the SIP/SDP level.

There may be other such cases which we will need to discuss at a later
stage

<jc>First of all, any SDP information has a full end-to-end meaning, that
is from end-user to end-user (or host).
The referenced section in Brunner draft is dealing with local information
with local meaning only. It is not stated how you get/determine/negotiate
this information, and this is normal as the semantics scope is limited to
the access network, or more exactly, just before entering a QoS domain.
Possible sources to obtain this local information can be SDP, but also
local policies stored in local databases, user profiles, etc.
Moreover, the term "bearer class" should be used very carefully, in order
to avoid any restriction or constraint to the session/application level.
BTW, what's a "bearer class" ? is it defined somewhere ?</jc>

Regards /Gabor

---

From: [email-masked] (Gabor Fodor)
Date: Fri, 15 Mar 2002 11:07:37 +0100 (MET)

Hi Juan-Carlos,

> that are out of the scope of the NSIS WG" </jc>
Yes, I agree with this formulation.

> local policies stored in local databases, user profiles, etc.
Yes, exactly. The SDP info may very well have end-to-end relevance 
at the session level, but that does not mean that any information that 
is mapped from it to some NSIS parameter set also needs to be carried end-to-end
at the _bearer level_. But some pieces of information that is carried
end-to-end at the session level (e.g. quite explicit information
about a voice codec in form of mime) may be useful at the bearer level as well 
(as a local info). Outside of that domain this level of detail 
at the bearer level is not needed: in an edge-to-edge segment for instance, 
maybe a peak rate is quite enough.

> BTW, what's a "bearer class" ? is it defined somewhere ?</jc>
Probably there is no formal definition, for the sake of this discussion
I was using the terms "bearer (service)" and "bearer class" 
to designate a L3 service.
In this sense, you can consider e.g. the controlled intergated service
as a "bearer" service. I am happy to use other terminology as long as
we agree on the meaning of it. 

/Gabor

---

From: [email-masked] (Gabor Fodor)
Date: Fri, 15 Mar 2002 12:01:15 +0100 (MET)

Juan-Carlos,

> 
> Hi Gabor,
> 
> Concerning the SDP story, I agree with you that not all the SDP information
> will be mapped to NSIS information, but surely all or almost all the SDP
> information *will be used by the application level* to derive the needed
> NSIS information.
Yes, I was discussing more the issue what info needs to be carried at the
bearer level (which is a separate issue from what info is used to do the
session-bearer mapping).

> My understanding is that this is fully inline with my original proposal,
> that is "the mapping on NSIS information ... is out of the scope of the
> NSIS WG"
Yes, that is fine. 

> 
> Concerning the term "bearer class", I agree that maybe the term itself does
> not matter, providing that there is a clear agreed definition. Now I know
> what you were referring to; I don't love the usage of the word "class" in
> this context, because generally this means a group of things, entities,
> etc. having common characteristics, which is not the actual case.
> 
> This is surely an issue in Brunner draft, where the expression "QoS Service
> Class" is defined as "specify the QoS requirements of a traffic flow or
> aggregate"; I fear that the word "class" is also very confusing here. As an
> example, this definition does not match the 3GPP definition of "QoS Class"
> (conversational, streaming, interactive and background).
> 
I am certainly open to use other terminologies as long as we
agree to a common definition.

Regards /Gabor
> 
> 
> 
> 
> [email-masked] (Gabor Fodor) on 15/03/2002 11:07:37
> 
> > > > question I'm raising is more "Is in the context of NSIS to define
> ways
> > of
> > > > there is no standardized way to exchange and negotiate QoS
> information
> > at
> > > > question I'm raising is more "Is in the context of NSIS to define
> ways
> > of

---

From: [email-masked]
Date: Fri, 15 Mar 2002 13:30:58 +0100

Hi Andreas,

Yes, it is clear now that the session/application level negotiation of QoS
related information is out of the scope of NSIS.
I know the draft you are talking about, and there are also some other
drafts concerning this subject in MMUSIC.
So, in order to avoid to mix all debates, I propose to continue de
discusion on the QoS question in the application level on the MMUSIC
mailing list.

Best regards
Juan Carlos

"Andreas Kassler" <[email-masked]> on 15/03/2002 13:24:17

To:   Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL, "Gabor Fodor"
      <[email-masked]>
cc:   <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject:  Re: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions

Hi Juan,
> information *will be used by the application level* to derive the needed

I completely agree on this issue. It may be of interest for NSIS, that
there
is a
draft related to SDPng that exactly describes requirements for that. It is
draft-guenkova-mmusic-e2enp-sdpng-00.txt, that is available from:
http://www-vs.informatik.uni-ulm.de/ietf/mmusic/sdp-ng/drafts/draft-guenkova

-mmusic-e2enp-sdpng-00.txt
The idea is to negotiate application level QoS parameters like frame rate,
size, quality,..
and capabilties like codecs using SDPng and provide a set of potential QoS
contracts
at application/session level that can be used to describe alternative QoS
parameters
for a multimedia session. It is then the responsibility of a terminal to
proceed with
network ressource reservation (if it likes to do so) using e.g. NSIS. But
the mapping
from application level QoS to network related QoS parameters (like
bandwidth, loss rate)
should be out of the scope for NSIS.

> (conversational, streaming, interactive and background).
Kind regards, Andreas

---

From: "Schneider, Marco" <[email-masked]>
Date: Fri, 22 Mar 2002 13:44:22 -0600

Well said,

Marco

> -----Original Message-----
> [mailto:[email-masked]]
> Sent: Friday, March 15, 2002 1:59 AM
> To: [email-masked]; [email-masked];
> [email-masked]'
> Cc: [email-masked]
> (Document link: Listes
> information at