Abdul Malick wrote:
>
> Hello i have just joined the list. If i am giving any point that has been
> discussed already please pardon me.
> I haven't gone through the draft that you are talking about. I am just
> trying to see if my comment could throw some light on the below pasted
> paragraph.
>
> >>this seems interesting as idea, can you extend a bit on it ? how would
> >>one characterise a well-known service ? by indicating a certain service
> >>level in terms of throughput, delay, jitter, packet loss ? so why
> >>couldn't these parameters then not be explicitly in an SLS ?
>
> I think since services are well defined in the standards (like EF PHB and
> AF PHB group) the customer domain(upstream) can simply use
> the names (like AFx.y or EF) rather than code points to request service from
> the provider domain and possibly the Corresponding codepoint that the domain
> used for that corresponding service(which would typically be used for
> remarking by the provider domain).
well, a PHB(G) is not the same as a service, it should rather be seen as
a building block to construct services. The service is actually the
resulting behaviour from ingress link to egress link, when some specific
packet treatment has been adopted at each hop in a domain. Therefor, i
would not overload the AFx.y and EF codepoints at the edge to indicate a
_specific_ service.
> If we are talking about some properietary
> services that are not defined in the Standard(rfc) then definitely there has
> to be a clear understanding about that in the customer domain. The other way
> as you said would be to quantify the charecteristices like throughput,
> jitter, etc on some scale and request the provider domain for that
> requirement along with the Codepoint used by the customer domain(for
> remarking) using the SLS.
the SLS can carry both a request for a qualitative service, or a
quantitative service, that should be applied between the points
indicated in the _scope_, for the correlated stream of packets
identified by the _flow id_
the offer provided by the transport provider may indicate a codepoint to
be used to mark that flow (by the customer)
> The provider domain can then take a decision on the CoS (including
> properietary) to be given to satisfy the requirement subjected to avaiabilty
> of resources at the time of service provisioning.
>
> Please comment on this.
>
> We (in our company) have implemented DiffServ EF, AF and BE CoS. We are
> looking to implement SLS. Any input in this regard is
> solicited
>
> Can someone kindly give me the link to [tequila/sls]
>
http://search.ietf.org/internet-drafts/draft-tequila-diffserv-sls-00.txt
cheers
Yves
> Thanks & Regards
> Malick
>
> ----- Original Message -----
> From: Yves T'Joens <yves.tjoens@alcatel.be>
> To: <sls@ist-tequila.org>
> Cc: <brunner@ccrle.nec.de>
> Sent: Tuesday, October 17, 2000 12:53 PM
> Subject: Re: [tequila/sls] comments on the TEQUILA draft by W. Almesberger
>
> Carlos Alberto Kamienski wrote:
> >
> > > > Carlos, Yves,
> > > >
> > > > In the context of the draft, the DSCP is a mean for a flow
> > > > specification. If it is signalled by the network, it is specified in
> the
> > > > offer from the network. The DSCP specifed in the SLS draft has in my
> > > > understanding nothing to do with the DSCP the packets are market in
> the
> > > > network. But it can be used for the traffic specification.
> > > >
> > >
> > > totally correct. DSCPs at the ingress link are just another way of
> > > indicating a to be differentiated flow.
> > > cheers
> > > Yves
> >
> > Why use the same name for a different think if this work is beginning from
> > scratch ? (there are no historical reasons for it).
> > Is it not a misuse, since the acronym DSCP has been defined by the
> > diffserv wg ?
>
> not particularly, it is the official name for a field in the header. in
> the core off the network, it is used as guide for per hop behaviour
> treatment, at the access, it could be used to bind it to some service
> contract.
>
> >
> > I my opinion there should be a field in the SLS for specifying exactly the
> > service one has in mind. It may be a well-known service identifier or a
> > identifier that has just a peer-to-peer meaning. I cannot see a
> > negociation process where both sides are able to understand clearly other
> > side's idea of the service just by observing some fields in the SLS (for
> > any service one can ever imagine!).
> >
>
> this seems interesting as idea, can you extend a bit on it ? how would
> one characterise a well-known service ? by indicating a certain service
> level in terms of throughput, delay, jitter, packet loss ? so why
> couldn't these parameters then not be explicitly in an SLS ?
>
> > Regards,
> >
> > Carlos
>
> cheers
> Yves
-- +------------------------------------------------------------------+ | Yves T'Joens | | Project Manager Internet Access and Edge | | Network Strategy Group | | Francis Wellesplein, 1 phone : +32 (0)3 240 7890 | | 2018 Antwerp fax : +32 (0)3 240 9932 | | Belgium email: yves.tjoens@alcatel.be | +------------------------------------------------------------------+
This archive was generated by hypermail 2b29 : Tue Oct 17 2000 - 17:26:20 CEST