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

From: [email-masked]
Date: Fri, 15 Mar 2002 11:37:43 +0100

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.
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"

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).

Best regards
Juan Carlos

[email-masked] (Gabor Fodor) on 15/03/2002 11:07:37

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,

> 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>
Yes, I agree with this formulation.

> <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.
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.

> 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>
>
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

>
> [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,
>
> 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
> > From: [email-masked]
> > Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions
> > To: [email-masked] (Gabor Fodor),
[email-masked],
> >         "[email-masked]'" <[email-masked]>
> > Cc: [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.);
> OK
>
> > 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.
> 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.
>
> <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>
>
> > 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)."
> 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).
>
> <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>
>
>
> >
> > Comments ?
> > Best regards
> > Juan Carlos
>
> Regards /Gabor
>
> >
> > ---------------------- 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: "Andreas Kassler" <[email-masked]>
Date: Fri, 15 Mar 2002 13:24:17 +0100

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