DJamel,
You are right in a business point of view, but we are talking about the
technical part of the specification of the service only. It is a
decision of the ISP if he wants to offer 25ms AND 50ms delay kind of
service or just fix one. Thats the freedom the ISP needs and which
allows him to differentiate against his competitors.
Marcus
"DJamel H. Sadok" wrote:
>
> Yes but these FEW grades may be seen as relative variations to a SINGLE
> basic well known service level, what I think is unlikely is having
> end-users (and even ISPs in some scenarios) negotiating the merits of
> absolute services with 25ms Vs. 50ms Vs. other delay values. Admission
> control and signalling may generate large processing overheads otherwise.
>
> DJamel
>
> On Mon, 30 Oct 2000, Jon Crowcroft wrote:
>
> >
> > In message <Pine.GSO.3.95.1001030075218.2736D-100000@zumbi>, "DJamel H. Sadok"
> > typed:
> >
> >
> > i dont agree
> > its highly likely that next generation telephony will have several
> > grades of voice call HIGHER than current toll quality (e.g. for music,
> > for conference calls where 2.5D is useful, for peopel with hearing
> > difficulty etc etc)
> > >>I think that it is very unlikely that we see customers asking their ISPs
> > >>for different voice service levels, probably they won't even know and/or
> > >>care of picking up one as long as they get a voice grade of service
> > >>similar to existing fixed telephony services. IMHO, I would say that one
> > >>way of describing services would be to say that a given application or
> > >>end-to-end service should receive a treatment that is
> > >>similar/equivalent to an end-to-end voice service. This assumes that ISP'=
> > >>s
> > >>know what a voice grade service is and are then able to set the resources
> > >>for it. If we throw in too much service specifications onto the service
> > >>granularity, as it seems to be the case from the tequila and other
> > >>documents, I think that although the desired result seems desirable its
> > >>complexity may not reasonable. This is somehow similar to the DiffServ
> > >>approach, let's try to keep things simple. Why not standardise or specify
> > >>few (3 or 4) discrete service classes and fit the rest of the negotiation
> > >>within this simple framework?=20
> > >>
> > >>Regards,
> > >>DJamel
> > >>
> > >>
> > >>On Wed, 25 Oct 2000, GARBISU Jean-Pierre FTRD/DMI/CAE wrote:
> > >>
> > >>> Hi
> > >>> About the "Network Services", even if it doesn't (perhaps) fit exactly =
> > >>what
> > >>> S. Salsano have in mind, I would like to add the following :
> > >>> IMHO these network services are essential.
> > >>> I can't see how any kind of customers'e2e SLSs could be individually
> > >>> processed in the backbones supporting QoS services.
> > >>>=20
> > >>> To give an example, VoIP. One could imagine that all customers of an IS=
> > >>P
> > >>> don't ask for exactly the same SLS's metrics e.g some customers ask for=
> > >> 100
> > >>> ms OWD between their CPEs, others ask for 80 ms, other for 120 etc (bas=
> > >>ed on
> > >>> different gateways needs, different access lines speeds etc.). The ISP =
> > >>could
> > >>> decide to implement only one VoIP network service wrt the OWD metric (e=
> > >>.g.
> > >>> 50 ms) between its PoPs instead of implementing (within all its backbon=
> > >>e QoS
> > >>> toolbox : TC, TE, etc.) 3 VoIP OWD metrics. The "generic" network servi=
> > >>ce in
> > >>> the core permits to handle varied specific e2e SLS.
> > >>>=20
> > >>> Another example could be ERP applications (e.g. transactional business
> > >>> critical applications). All customers don't share the same ERP apps but
> > >>> generally one could imagine that customers could ask for a prioritized =
> > >>e2e
> > >>> QoS service for them (e.g. somewhere between real time needs and best e=
> > >>ffort
> > >>> needs; OWD varying between a few hundred ms and a few secondes). The IS=
> > >>P
> > >>> could decide to implement one or two generic ERP network services which
> > >>> should cover the needs of a large variety of customers applications ins=
> > >>tead
> > >>> of trying to implement specific PoP to PoP service per ERP type.=20
> > >>>=20
> > >>> Finally it seems well established that the closer you get from the core
> > >>> networks, the fewer CoS (if ever) and dynamicity you should consider,
> > >>> compared to greater variety of CoS and dynamicity you can try to implem=
> > >>ent
> > >>> at the access.
> > >>> That's why mapping of (possibly numerous) e2e SLS on (few) PoP to PoP
> > >>> network services seems very attractive.
> > >>>=20
> > >>> Best regards.=20
> > >>>=20
> > >>> jeanpierre.garbisu@francetelecom.fr=20
> > >>>=20
> > >>>=20
> > >>> -----Message d'origine-----
> > >>> De=A0: Michael Smirnov [mailto:smirnow@fokus.gmd.de]
> > >>> Envoy=E9=A0: mercredi 25 octobre 2000 00:52
> > >>> =C0=A0: sls@ist-tequila.org; brunner@ccrle.nec.de
> > >>> Cc=A0: cak@cin.ufpe.br
> > >>> Objet=A0: Re: [tequila/sls] predefined services / SLS ?
> > >>>=20
> > >>>=20
> > >>> Hi,
> > >>>=20
> > >>>=20
> > >>> On Tue Oct 17 17:42:18 2000 Stefano Salsano wrote:
> > >>>=20
> > >>> <...>
> > >>> > What is interesting is that we found the need to have pre-defined
> > >>> > SLSs (we called it "Network Services" but the name can be misleading)=
> > >>:
> > >>> > for ease of negotiation and implementation only a subset
> > >>> > of parameters can be specified, while the others are given by default
> > >>> > with reference to a small set of "well known services".
> > >>> > This is in perfect agreement with your idea that a well-known service=
> > >>=20
> > >>> > identifer is just a compression of the SLS for ease of negotiation.
> > >>>=20
> > >>> can you provide examples of "Network Services"?
> > >>>=20
> > >>> Thanks in advance
> > >>>=20
> > >>> Michael
> > >>>=20
> > >>
> >
> > cheers
> >
> > jon
> >
> >
--Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd.
E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner
Adenauerplatz 6 D-69115 Heidelberg Germany
Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 09:43:04 CET