Subject: Re: [Diffserv] I-D ACTION:draft-ietf-diffserv-ba-def-00.txt

From: Dan Grossman <[email-masked]>
Date: Thu, 16 Mar 2000 11:37:22 -0500

The authors never responded most of these.  Brian indicated that Kathy had 
given the most thought to the draft, and would likely reply when she got back 
from vacation.  I can certainly understand why that might not have happened.  
But the questions still stand.  Here is a summary thus far, before the 
conversation dropped.

> A number of issues, questions and concerns.  First the minor mechanical 
> hassles, then the broad implications, then a lot of things that need 
> clarification.
> 
<<snip...>>
 
> 3) The semantics of a BA seems to have changed between RFC 2475 and this 
> draft.  The definition ("... crossing a link in a particular direction") 
> pretty clearly (at least in my mind) implies that its scope is hop-by-hop.  In 
> the draft, it seems to be a kind of odd beast which isn't quite end-to-end, 
> nor is it hop-by-hop.  Flows can apparently join and leave a BA anywhere in 
> the DS domain.  In fact, it looks like this draft is looking do redefine a BA 
> to be some kind of a spanning tree of the DS domain.  Would the authors 
> explain?  

To which Kathy replied:
> First, using a descriptive phrase does not mean we are inventing
> "new terminology"; in fact, it sometimes means that we are
> conciously avoiding the use of "terminology".

And Brian replied
> I don't think the original concept of BA was intended to be a single hop;
> if that's what 2475 says we may need to adjust it. Yes, the "new" BA is
> edge to edge of a DS network.

To which I replied:

> It wasn't clear, but certainly implied.  Next questions:  is there such a 
thing as a 'unicast' or a 'multicast' BA?  If so, can a unicast BA have more 
than one ingress edge node or more than one egress edge node?

> 4) The draft seems to have gotten religion about measurable, quantifiabile, 
> characteristics, for which I applaud it.  It does seem a bit difficult to 
> reconcile this with the relative PHBs, as in the legacy class selectors and to 
> a lesser extent AF.  
>
To which Brian replied: 
> That would lead to soft metrics.
Leading me to ask:
>Um, what is a 'soft' metric?  

> 5) On a related topic, most of parameters  will be quite sensitive to network 
> topology, route selected and link characteristics, as well as the capabilities 
> and configuration of the DS nodes on the path.  What I think we're saying is 
> that each the value for each measureable, quantifiable parameter is in fact 
> the worst case of any path along the spanning tree.  Or, actually, the worst 
> spanning tree that could possibly result from a route flap.   Which might be 
> quite a bit worse than it would actually be for many feasible paths.  Or, in 
> another words, the parameter values experienced by  two flows belonging to the 
> same BA, which enter and/or leave the DS domain at different DS edges may 
> differ considerably.
Brian's response:
> I think that will depend on the BA.
Dan's reply:
> Can you elaborate?
> 
> 6) The draft explicitly refers to pinned routes from time to time, and hints 
> at them elsewhere.  Except for MPLS, do any standards track RFCs allow for 
> route pinning?
> 

Brian:
> I don't think so; the QOS Routing RFC certainly discusses this issue.
Dan:
> Is this a problem?  As in are we relying on mechanisms that don't exist?
Kathy: 
> The use of any reference to this was merely to state that IF
> a BA were relying on some sort of "pinned" routes (and we wanted
> to be general here), the description should explicitly say so.
> That is ALL. I'd be interested to hear if this is a widely
> shared view, that the document is somehow advocating or assuming
> them, so that we can fix this in the next revsision.
To which I note that there are all kinds of other things that don't exist in 
IP that a BA could in principle rely upon.  If it doesn't exist, a BA that 
relied upon it wouldn't be implementable, would it?

> 7) Can anybody think of an example of a parameter which is absolute, rather 
> than bounded?  We couldn't do that with ATM, despite its very fine-grained 
> mechanisms and conservative approach to aggregation.
> 
> 8)  I assume that it's intended that a central assumption is that each flow 
> will be shaped to the agreed TCA before it enters the DS domain and policed at 
> the DS edge node;  otherwise, the parameters of the BA do not obtain.
> 
Brian: 
> Yes
> 9) The authors clearly have in mind some kind of relationship between a 
> service and a BA.  
Brian: Er, not consciously.
> 
> It is not clear to me what that might be.  Can a BA can be 
> made to carry multiple services?  Is it possible for more than one BA to have 
> the same PHB (i.e., with different DSCPs) such that the edge-to-edge 
> characteristics experienced by packets belonging to the BAs might differ?  If 
> not, do we not implicitly limit the number of distinct services that can be 
> offered by a DS domain? How will defining BAs address the difficulties the 
> group (and also ISSL and the ATM Forum) has been struggling with in not having 
> services in its charter?
> 
> 10) There is a critical point in the introduction: 
>  If the properties of a BA using a particu-
>  lar PHB hold regardless of how the aggregate mutates as it 
>  traverses the domain, then that BA scales. If there are limits to 
>  where the properties hold, that translates to a limit on the size or 
>  topology of a DS domain that can use that BA. Although useful 
>  single-link BAs might exist, BAs that are invariant with network 
>  size or that have simple relationships with network size and 
>  whose properties can recovered by reapplying rules (that is, form-
>  ing another diffserv boundary or edge to re-enforce the rules for 
>  the aggregate) are needed for building scalable end-to-end quality 
>  of service."
> How do we know that the existing PHBs allow construction of BAs that have this 
> property?
> 
Perhaps Kathy et al's draft of this morning addresses this.   But I remain 
sceptical. 

By the way, the WG charter apparently changed on February 14.  Perhaps I 
missed the discussion on that?

Dan

_______________________________________________
diffserv mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Mar 2000 12:32:58 -0600

Hi Dan,

Kathie *will* respond to your points.

Dan Grossman wrote:
...
> By the way, the WG charter apparently changed on February 14.  
> Perhaps I missed the discussion on that?

You certainly missed the final round of discussion, because the
IESG has the last word on charter updates. But the bulk of the changes
were in a message to the WG on December 16, 1999. I only saw one comment
on the list, from Joel Halpern, which produced a small wording change.
The changes from the IESG discussion were also small.

  Brian

---

From: Dan Grossman <[email-masked]>
Date: Thu, 16 Mar 2000 14:13:43 -0500

Hmmm.  Looks like I stand corrected.  It does appear in the mailing list 
archive, in with the discussion on queues...  but I don't remember having seen 
it and can't seem to find it on my own archive.  Maybe an email glitch.

Am I the only one who's not certain that this is a path we should follow?

---

From: Kathleen Nichols <[email-masked]>
Date: Thu, 16 Mar 2000 13:41:46 -0800

Dan Grossman wrote:
... Next questions:  is there such a
> than one ingress edge node or more than one egress edge node?

I suppose there could be a multicast BA. Do you have a description in
mind?
I believe a BA should be defined assuming there is more than one ingress
edge node and more than one egress edge node, but retricting it might
be part of the specification. I assume in that case there would have to
be some applicability.

> >Um, what is a 'soft' metric?

I don't know what Brian meant here, so I can't respond for him. But what
we are trying to say is that the metrics for a BA need to be specific.
If
the BA is based on class selectors, then I would assume (but a future
description might prove me wrong) that part of the BA description would
include some additional information on how the CS PHB used for that BA
needs to be configured. However, we want to be aware that for some kinds
of BAs, for example something modeled on "best effort", it might be
explicitly stated that no particular delay bound is being given.

> > I think that will depend on the BA.

Again, can't speak completely for Brian, but I think Brian may be saying
quite literally that it "will depend on the BA". We tried to say that
such
effects should be taken into account or discussed in the BA description.
Sure, one can't specify everything, so maybe this won't work. Remember
this is draft -00 and we're trying to get a sense of what will work and
what won't. BAs are meant to be another technical building block in the
diffserv toolbox. We've had two basic kinds of feeback from potential
service-offerers: 1) that more technical info on how to hook this stuff
up is needed and 2) that enough tools are provided, that they will
specify
their own services and figure out their own provisioning. So we are
looking
for a way to deal with both of these. This seemed to be a likely
approach.

> relied upon it wouldn't be implementable, would it?

So, I found this paragraph in section 5.5:

"In most cases, BAs will be characterized assuming lossless links, no
link failures, and relatively stable routing. This is reasonable since
otherwise it would be very difficult to quantify behavior. However,
these assumptions must be clearly stated. If additional restrictions,
e.g., route pinning, are required, these must be stated. Some BAs may be
developed without these assumptions, e.g., for high loss rate links, and
these must also be made explicit."

To me, it says "state your assumptions". But I think a problem arises in
the
last sentence. "Some BAs may be developed without these assumptions"
refers
to the assumptions of the first sentence, not the preceding one. Looks
like I
need to fix that. I propose to interchange the last two sentences of
that
paragraph. That was the only mention I could find of route pinning, but
I
may have missed something.

> > mechanisms and conservative approach to aggregation.

Not sure what you mean here. Do you mean would there be any parameters
that would say "you will get a bandwidth of R" as opposed to "you will
get a bandwidth no [greater,less] than R"? Do you think we should reword
the discussion of parameters?

> > the DS edge node;  otherwise, the parameters of the BA do not obtain.

I agree with Brian. Of course, this depends on there being a TCA. One
assumes such a thing could be rather minimal for a "best effort" or
"bulk handling" type BA.

> > group (and also ISSL and the ATM Forum) has been struggling with in not having

Part of the answer to this is to continue as above about BAs being part
of the diffserv toolbox. Two ISPs might offer what looks like the
same "service" using different BAs. We don't expect an ISP to tell
you what BAs it is using (if, indeed, it is using one that has been
publically defined). What we expect an ISP to tell you is something
about the service you are purchasing. This might be metrics that
are very closely related to the BA metrics, but then again, it might
not be. Services appear to have more commercial and topological
sensitivities specific to a particular provider than what the IETF
will get involved in. 

This distinction is what we tried to get at in the next to last
paragraph of section 1.0.

> > How do we know that the existing PHBs allow construction of BAs that have this

Well, constructing BAs is supposed to be a good test. We would have
hoped
that some of this would have been thought out in advance. If the PHB is
intended
for a single-link kind of BA, then it doesn't need to have this
property.

> Perhaps Kathy et al's draft of this morning addresses this.   But I remain

Speaking for myself and my co-authors, we appreciate your vote of
confidence. :)
And the draft finished last week, just still in the queue.

	Kathie

---

From: Siamack Ayandeh <[email-masked]>
Date: Fri, 17 Mar 2000 08:11:57 -0500

Dan

I can not see any emails on Feb-14 archive. What is this change in
the charter. Could you please forward it to the list so we can all see
it.

Thanks, Siamack

---

From: Dan Grossman <[email-masked]>
Date: Fri, 17 Mar 2000 15:17:49 -0500

Kathie,
Thanks for getting back on this...
> I suppose there could be a multicast BA. Do you have a description in
No, I'm still trying to understand the implications of the way the draft is 
using BAs.  I have to assume that DiffServ will need to support multicast as 
well as unicast (this is a valid assumption?).  When a BA was strictly a 
hop-by-hop thing, the question would not have come up.

What I'm really looking for is an expanded description of toplogical 
implications of this new understanding of BAs.  I now understand that a 
specific BA definition will have to address topology constraints.  However, it 
still isn't clear what the range of possible topologies might be.  

> be part of the specification. I assume in that case there would have to
So in the default case, the topology of a BA instance is an acyclic directed 
graph having one or more ingress edge node, one or more egress edge node, one 
or more interior node.  A DS domain has more than one such BA instance (?).  
The edges (of the graph) of one BA instance are disjoint from the edges of 
another BA instance.  

Is that right?  Are there other assertions you can make about BAs?  (And yes, 
some formalism really is needed here, if for no other reasons than to nail 
down the defintion and to make sure that it's consistent.)
> explicitly stated that no particular delay bound is being given.
I'll be interested to see a such a BA description.

> what won't.
Now I'm really confused. How far along is your thinking on this?

> BAs are meant to be another technical building block in the
Some concerns here...  first, who's this 'we' tht got the feedback?  Is this 
an open dialog?  And second, aren't there other stakeholders than just service 
offerers? 
> may have missed something.
I'd have to check.  It probably was.  But the point is that a BA mustn't 
assume any mechanism that doesn't exist.
> Not sure what you mean here. 
We realized that there would be statistical bounds on any parameter.  For 
example, maximum cell transfer delay (the parameter which is associated with 
an ATM connection) is defined as the (1-\alpha\) quantile of the cell transfer 
delay distribution.

>Do you mean would there be any parameters
> get a bandwidth no [greater,less] than R"?
Kinda.  Although what we're really saying is that "if you transmit at a 
bandwidth no greater than R, your packet loss ratio will be (1-L) over a 
statistically significant sample of packets."  That is, two measurement points 
at the edge of a DS domain can't measure bandwidth inside the domain, only 
loss, delay and jitter.

> Do you think we should reword
I think so, and would be willing to help do so when all this has had some time 
to settle in. 
> assumes such a thing could be rather minimal for a "best effort" or
Ok.  Probably should say that in the draft.  Or rather the assumptions on that 
should be included in the individual BA drafts.
> of the diffserv toolbox. 
But continuing that metaphor, tools get used to [fabricate and] assemble 
components into systems, and systems have end objectives.  If we can't talk 
about the end objective, how do we talk about systems?  Hell, even I don't 
walk into the tool department at Home Depot and buy things without some idea 
of how I'm going to use them :-)

> Two ISPs might offer what looks like the
> same "service" using different BAs.
ok
> We don't expect an ISP to tell
> you what BAs it is using
So 'you' get an instance of a service and a (set of) DSCPs to identify it, and 
the ISP maps packets with that (those) DSCPs to a BA.  But DiffServ specifies 
BAs (which 'you') don't know or care about, but not services (which 'you' do). 
 The logic escapes me.  Especially since 'you' is several entities: the human 
administrators who are the 'customers' for the service (and who might or might 
not have deep understanding of how all this works);  the end users (who 
probably don't); the devices connected to the DS edge (which sure would like a 
consistent set of services to work with and over, and definitely would not be 
thrilled at having to do different things for every ISP in the world); 
managers and policy servers (ditto).  And in the multiple domain case (which 
the draft explicitly does not address) other service providers.
 
> (if, indeed, it is using one that has been
> publically defined).
No standards track RFC is truly mandatory or exclusive (in the sense that the 
National Electrical Code or FCC part 15 is mandatory and exclusive). Service 
providers sometimes do non-standard things. 
    
> What we expect an ISP to tell you is something
> not be. 
But we won't write a draft to descibe what that should be?

> Services appear to have more commercial and topological
Yet Intserv, ITU-T and others have managed to define services over the past 
many years.  They recognize that commercial and topological sensitivities 
exist and explicitly declare them to be the service provider's problem.  The 
only time I've ever seen problems is years ago when some service providers 
tried to insert commercial terms and conditions into ISDN service definitions. 
 It is very possible to finesse this.

But I understand that this a a problem that will have to be solved outside of 
DiffServ. 

> Speaking for myself and my co-authors, we appreciate your vote of
I'm still trying to digest it. No judgement for or against, just need to 
understand the underlying assumptions.

> And the draft finished last week, just still in the queue.
Sure.  Just that the pre-announced version turned up Wednesday morning.  And 
thanks again for making it available in PDF  -- MUCH MUCH easier to download 
and read.

BTW, I'm not necessarily against doing BA definitions in DiffServ, and I'm not 
giving you a hard time for malicious or political reasons.... I'm just trying 
very hard to understand the implications of this, and not having much success. 
 And also pushing very hard to make sure that any RFC that ultimately comes 
out of this draft is understandable to implementors who are not on this 
mailing list.

By the way, it just occurred to me that there might be a problem with the 
current definition of BA, "a collection of packets with the same DSCP".  This 
would imply that packets that are members of the same PHB group but have 
different DSCPs (as in AF11 and AF 12) are not members of the same BA.  Is 
this intentional?

Dan

---

From: Dan Grossman <[email-masked]>
Date: Fri, 17 Mar 2000 15:57:45 -0500

Siamack,
The email in question was sent on December 16.  The charter was changed on the 
IETF working group charters website:  www.ietf.org/html.charters/diffserv-chart
er.html

Dan

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Mar 2000 16:49:28 -0600

...
> > I don't know what Brian meant here, so I can't respond for him.

One that is in terms such as "as much as possible" rather than "not less than N".

...
> > quite literally that it "will depend on the BA". 

Right. Some BAs might give consistent service at all edge points, and others
might not. If you've read Dinesh Verma's SLA book, he talks about "funnel"
and "cloud" SLAs - in the funnel case, one site that corresponds to the
neck of the funnel will have completely different parameter values
than the other sites the feed into the funnel. But the PHB would be the same
everywhere. 

...
> different DSCPs (as in AF11 and AF 12) are not members of the same BA.  Is

Well, it's an interesting challenge for the AF theorists to tell us whether
the parameters that characterize an AF11-based BA are independent of those
for the associated AF12- and AF13-based BAs. If they are not independent,
then your point is valid. I don't know the answer.

   Brian