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
- RE: [NSIS] section 3.5 in nsis-req-00.txt, Sectio… Juan-Carlos.Rojas
- RE: [NSIS] section 3.5 in nsis-req-00.txt, Sectio… Gabor Fodor
- RE: [NSIS] section 3.5 in nsis-req-00.txt, Sectio… Juan-Carlos.Rojas
- RE: [NSIS] section 3.5 in nsis-req-00.txt, Sectio… Gabor Fodor
- RE: [NSIS] section 3.5 in nsis-req-00.txt, Sectio… Juan-Carlos.Rojas
- RE: [NSIS] section 3.5 in nsis-req-00.txt, Sectio… Gabor Fodor
- Re: [NSIS] section 3.5 in nsis-req-00.txt, Sectio… Andreas Kassler
- Re: [NSIS] section 3.5 in nsis-req-00.txt, Sectio… Juan-Carlos.Rojas
- RE: [NSIS] section 3.5 in nsis-req-00.txt, Sectio… Schneider, Marco