Yves T'Joens wrote:
> Koch Berthold wrote:
> > on behalf of Werner Almesberger (EPFL) I'm sending his comments on the
> > TEQUILA draft.
Thanks, Bert !
> 1.2, paragraphs 3 and 4
[...]
> [Y: it is just an introduction, and gives a number of situations in
> which a standardized approach seems highly valid.]
So this looks like framework document material then. (I think we
should liberally apply Occam's Razor to the SLS draft. In order to
be useful, this document has to be very precise, so any peripheral
issues could easily confuse things.)
> 3.1, page 6, list.
> Why is (N,N) excluded ? What if I have two sites X and Y, each with
> a primary access link, and a backup link, and I want to describe
> the network service between the two sites ? Excluding (N,N) seems to
> require at least a justification.
>
> [Y: well, it is ok to indicate it, however, the semantics should then
> also be mentioned. does the flow id and traffic enveloppe that is
> described apply to any of the ingress points ? if so, than the service
> that is described can be decomposed in n* (1,N), and would be a short
> notation for this. we'll mention it in the next release.]
I was mainly thinking of a service like this: company X has two sites
A and B. ISP gives some assurances on traffic from A to B. Each site
is connected via two links/routers to the network of the ISP. The ISP
does not wish to reveal its internal structure in the contract with X
(e.g. simply because they're changing things every month anyway).
In this scenario, I don't think there's a natural mapping into
independent (1,N) SLS. Of course, one could introduce inter-SLS
dependencies ... :-(
> 3.1, general.
> Typical SLAs in use today include geographic references like "no more
> than X ms RTT to any of our routers in Europe". Example:
> http://www.uk.uu.net/customerservices/sla/tandcs/
>
> Such specifications are probably too difficult to express in a general
> formal way, so the current approach of ignoring them seems
> appropriate.
> Nevertheless, it may be good to mention them, simply due to their
> current practical relevance.
>
> [Y: agreed, this would be a newly defined scope then... agreed ?]
Maybe we can cleverly combine this with the next item ;-) What I
meant with "mention" was in a footnote or such, not in the formal
structure.
> 3.1, page 5, disclaimer.
> Isn't this sufficiently vague that one could simply say
> "[...] IP address, but it may also be any other mutually agreed upon
> identifier which uniquely identifies a boundary link."
So ... maybe this should then become "a set of". So "all our links
in Europe" could be one such set. Actually, it should be "the
customer ends of all our links in Europe". Vague enough.
> [Y: not particularly, MF could potentially also include DSCP as far as i
> know. Do you exclude DSCP for MF ?]
Ah yes, I mis-read this, sorry.
> 3.3, 2nd paragraph, and also section 3.4.
> Again, "excess" is a difficult concept if there are multiple levels
> of conformance.
>
> [Y: agreed.]
Yippee ! In Salzburg, we've been going around in circles on this one
for about half an hour ;-)
> 3.4, list "[...] reordering MUST be avoided when remarking [...]"
> These concepts are largely orthogonal. Re-marking should only be
> relevant at egress. Anything happening in the ISP network is
> opaque.
>
> [Y: how do you mean only at egress ? any transport provider is free to
> remark packets at ingress. Certainly to differentiate in and out of
> profile]
Yes, what I mean is that the SLS should only specify what comes
out of the network. The ISP is free to mark/remark/condition/whatever
wherever and as many times as they wish, as long as the SLS is not
violated.
> [Y: here you hit the most difficult problem to solve... We should go
> back and look for a measurement paradigm as in IPPM, or define ourselves
> some time intervals parameters...]
Good point. They have better material than my ad hoc suggestion.
> 3.5, disclaimer.
> Good point. Throughput indeed seems to be unnecessary.
>
> [Y: you mean ffs is solved ? ;-)
In my mind yes - unless somebody convinces me it isn't ;-)
> 3.5, "Qualitative performance guarantees"
> This seems far too specific. Why only 3*3 types ? A more generic way
> to express qualitative guarantees would be to make them relative, e.g.
[...]
> [Y: purely philosophical, as soon as you indicate <= 0.01, one has a
> quantitative SLS... I would leave the relative differences as operator
> specific, not to be defined in the SLS, the only thing you know is that
> e.g., green has better loss properties than red...]
Okay, let's leave out the "0.01". Nevertheless, there must be some
properties that can be verified, however general. And I think the
formal SLS model should be able to express them. (This doesn't have
to be conclusive - new rules can always be added when somebody
invents some new clever queuing algorithm.)
> 3.7, "downtime per year"
> The interval should be left open. It is quite common to find months
> there. (E.g. see UUNET example above.) Q: does reliability really
> belong
> into an SLS or is this rather SLA-only material ?
>
> [Y: i would argue that it is an SLS parameter. Not that every flow
> should be specified with one though...]
In any case, "downtime" may also be broader, e.g. a router failure or
any maintenance not covered by the contract may affect your ability to
reach one or several destinations, your ability to invoke a service,
etc. But yes, perhaps some providers may wish to add specific downtime
assurances on a per-flow(s) level.
> [Y: negotiation and definition of the SLSses seem to me to be pretty
> tied together, although this is certainly not obvious from this version
> of hte draft, agreed. ]
Agreed in the sense that the negotiation has to use something that
can be expressed in the language used for SLS'. But I think the SLS
for the invoked service can be narrower while still being useful.
Negotiation and such can then go to a different document ... (this
has also the advantage that work on a specification for invoked
SLS', which seem to be better understood at the moment, would not be
slowed by any haggling over negotiation issues.)
> [Y: i don't personally like the word bandwidth brokers, since different
> people think about different things when bandwidth brokers are
> mentioned. It is a given that services can be offered over diffserv
> capable networks, and somehow these services should be described at the
> edges of the network. Today this is highly static, and uses a form of
> fax-signalling. We just want to have an automated infrastructure for
> this...
Exactly ;-)
> [Y: I understand your doubts. let us try in the framework to give some
> good reasons why SLS negotiation should be mentioned along with the SLS
> formal formats.]
Again, I'm convinced that a separate document is a better place for
negotiation issues. They're close enough that this should be done in
the same working group, though, IMHO.
Cheers, Werner
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH Werner.Almesberger@epfl.ch / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
This archive was generated by hypermail 2b29 : Mon Oct 16 2000 - 14:49:51 CEST