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

Juan-Carlos.Rojas@alcatel.fr Fri, 15 March 2002 12:40 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27514 for <nsis-archive@odin.ietf.org>; Fri, 15 Mar 2002 07:40:55 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA16877 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 07:40:57 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16573; Fri, 15 Mar 2002 07:32:27 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16541 for <nsis@optimus.ietf.org>; Fri, 15 Mar 2002 07:32:24 -0500 (EST)
Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27395 for <nsis@ietf.org>; Fri, 15 Mar 2002 07:32:21 -0500 (EST)
From: Juan-Carlos.Rojas@alcatel.fr
Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id NAA17751; Fri, 15 Mar 2002 13:30:59 +0100 (MET)
Subject: Re: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions
To: Andreas Kassler <kassler@informatik.uni-ulm.de>
Cc: Gabor Fodor <Gabor.Fodor@era-t.ericsson.se>, john.loughney@nokia.com, brunner@ccrle.nec.de, nsis@ietf.org
Date: Fri, 15 Mar 2002 13:30:58 +0100
Message-ID: <OF417A99EC.583A5C75-ONC1256B7D.00444557@netfr.alcatel.fr>
X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/15/2002 13:30:59
MIME-Version: 1.0
Content-type: text/plain; charset="us-ascii"
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

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" <kassler@informatik.uni-ulm.de> on 15/03/2002 13:24:17

To:   Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL, "Gabor Fodor"
      <Gabor.Fodor@era-t.ericsson.se>
cc:   <john.loughney@nokia.com>, <brunner@ccrle.nec.de>, <nsis@ietf.org>
Subject:  Re: [NSIS] section 3.5 in nsis-req-00.txt, Section Exclusions


Hi Juan,
>
> 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.

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.

> 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
>
>
>
>
Kind regards, Andreas






_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis