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