Re: [MMUSIC] draft-guenkova-mmusic-e2enp-sdpng-00.txt
suresh.leroy@alcatel.be Mon, 11 March 2002 16:57 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 LAA14650 for <mmusic-archive@odin.ietf.org>; Mon, 11 Mar 2002 11:57:02 -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 LAA29200; Mon, 11 Mar 2002 11:55:28 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29173 for <mmusic@optimus.ietf.org>; Mon, 11 Mar 2002 11:55:22 -0500 (EST)
Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14558 for <mmusic@ietf.org>; Mon, 11 Mar 2002 11:55:17 -0500 (EST)
From: suresh.leroy@alcatel.be
Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g2BGsf506489; Mon, 11 Mar 2002 17:54:46 +0100 (MET)
Received: from alcatel.be ([138.203.33.40]) by bemail04.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002031117543950:1455 ; Mon, 11 Mar 2002 17:54:39 +0100
Message-ID: <3C8CE14B.8720DBEC@alcatel.be>
Date: Mon, 11 Mar 2002 17:54:35 +0100
Organization: Alcatel
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Teodora Guenkova <guenkova@vs.informatik.uni-ulm.de>
Cc: mmusic@ietf.org, jo@ipdialog.com, csp@isi.edu, "A. Kassler" <kassler@informatik.uni-ulm.de>, "Mandato, Davide" <mandato@sony.de>, Eisl Jochen <Jochen.Eisl@icn.siemens.de>
Subject: Re: [MMUSIC] draft-guenkova-mmusic-e2enp-sdpng-00.txt
References: <OFB7C173E6.D99FE22B-ONC1256B76.0059DAD1@alcatel.be>
X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/11/2002 17:54:39, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/11/2002 17:54:46, Serialize complete at 03/11/2002 17:54:46
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
X-BeenThere: mmusic@ietf.org
Content-Transfer-Encoding: 7bit
Dear Teodora, I'm reading your draft with great interest as it is very related with draft-bos-mmusic-sdpng-qos-00. Below are some first quick remarks/questions. I hope this can start a fruitful discussion. Under QoS parameters you also put parameters like video frame rate, sampling rate, ... . This parameters are indeed interesting and affect the QoS level as perceived by the end-users. However the transport level should be completely service independent (doesn't care if the IP packets carry audio or video). Therefor we consider this to be more codec related information than true QoS information. If a user wants a higher video frame rate this will automatically result in a higher bitrate, etc. The QoS information should be general enough to be used in access and backbone networks and be service independent (meaning independent the same for audio, video, ... streams). Putting codec specific information as frame rate, etc endangers the service independence, as with the development of new codecs you might be forced to add new parameters. So to conclude the extra information you mention is useful but should be considered as codec information not QoS information. Section 6 related work: "The authors of [5] suggest that some IMs along the negotiation path may influence the negotiation, though in general having nothing to do with the data. According to such a protocol model the network is not transparent." It is true that some of the IMs along the path have nothing to do with the data (e.g. 'home' service provider in roaming scenarios). However the end-users service provider is the one with which the end-user has a QoS contract. Therefor your service providers IMs should be able to modify the QoS requested by the end-users even though data doesn't traverse his network. The model we used in our draft is: the end-user has a QoS contract with his service provider. The service provider on his turn has agreements with the access/transport providers. So according to me this makes the protocol very network transparent. In section 3 first bullet point, you state "A QoS contract shall capture user's QoS expectations, as well as network provider policies .... (this means for instance to control that the QoS levels fit into the predefined policies, or to control the amount of resources by up-/downgrading QoS upon detection of QoS changes/QoS violations)". Isn't this in fact also demanding that IMs outside the data path can influence the QoS? Is the network provider the same as the service provider? Regards, Suresh Teodora Guenkova wrote: > Dear MMUSIC WG Folks, > > we have submitted draft-guenkova-mmusic-e2enp-sdpng-00.txt, that > should appear in the archives soon. Until it does, it is available > from: > > http: > /www-vs.informatik.uni-ulm.de/ietf/mmusic/sdp-ng/drafts/draft-guenkova-mmusic-e2enp-sdpng-00.txt > > This document takes inspiration from > draft-ietf-mmusic-sdpng-trans-00.txt > and analyzes issues for providing both sedentary and > mobile users of multiparty, multimedia communication services > with efficient mechanisms for coping with unstable network > conditions and limited resource availability, conforming to the > users' QoS requirements and expectations. To this extent, the > concept of a comprehensive and efficient end-to-end QoS signaling > mechanism is needed, dealing not only with capabilities/QoS > negotiation, but > also with efficient re-negotiations and coordinated resource > management. Requirements of a protocol (thereinafter, the > "End-to-End Negotiation Protocol" - E2ENP), as well as a > possible implementation thereof, based on extensions of SDPng > and on the use of SIP, are then discussed. Finally, differences > and/or synergies with existing solutions and proposals > (especially with draft-bos-mmusic-sdpng-qos-00.txt and > draft-bos-mmusic-sdpqos-framework-00.txt), as well as security > considerations, are provided. > > Regards, > -- > ----------------------------------------- > Teodora Guenkova-Luy > Dept. Distributed Systems, University of Ulm, > Oberer Eselsberg, 89069 Ulm, Germany > > Tel.: +49 (0731) 502-4148 > FAX: +49 (0731) 502-4142 > > e-Mail: guenkova@vs.informatik.uni-ulm.de > ----------------------------------------- > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] draft-guenkova-mmusic-e2enp-sdpng-00.txt Teodora Guenkova
- Re: [MMUSIC] draft-guenkova-mmusic-e2enp-sdpng-00… suresh.leroy
- Re: [MMUSIC] draft-guenkova-mmusic-e2enp-sdpng-00… Andreas Kassler
- Re: [MMUSIC] draft-guenkova-mmusic-e2enp-sdpng-00… suresh.leroy
- Re: [MMUSIC] draft-guenkova-mmusic-e2enp-sdpng-00… Mandato, Davide
- Re: [MMUSIC] draft-guenkova-mmusic-e2enp-sdpng-00… Juan-Carlos.Rojas