Subject: [Diffserv] comments on the bulk handling draft

From: "Yoram Bernet" <[email-masked]>
Date: Mon, 11 Dec 2000 10:43:56 -0800

First of all - i'm glad to see this. I think that it is a useful and
necessary pdb. I'll comment on it, realizing that I have not been
keeping up with the mailing list and that I missed the last IETF. So -
pls pardon if I am restating the obvious or raising issues that have
already been addressed/resolved. 

One general comment I have relates to the name chosen for the pdb. I
think that the name 'bulk handling' does a disservice to the pdb. In
certain cases, there is an overlap between applications that 'bulk
handle' and the service provided by the pdb. However, there are many
bulk handling applications that cannot use the pdb and there are
applications of the pdb that extend beyond bulk handling. 

For example - 'transfer all accounting records from new york to london
each night' can be considered a bulk handling task, yet would likely not
be happy with what is effectively, less than best-effort (LBE) service.
In addition, I see one of the primary applications of the bh pdb in the
incremental deployment of aggressive multimedia applications (that use
non-adaptive UDP). IT managers are reluctant to deploy (for example)
streaming media over wan links because they cannot control the impact of
these apps on the wan link resources. One way in which we might see
these more likely to be deployed is if some controlled amount of the
multimedia traffic could be given priopritized service (appropriate for
the media), but any amount beyond this would be relegated to the bh pdb
(to prevent it from seizing network resources required for best-effort.
Based on these considerations - I would rather  this pdb be called the
LBE (less than best effort pdb) rather than the bh pdb - I think is is a
much more descriptive name. 

Another general comment - wasn't just this type of pdb proposed
previously? I think that it was proposed as draft-mumble-lbe-xx. I can't
remember the authors, but - one may have been Roland Bless. Whoever they
were, those authors deserve acknowledgement. 

As for specific comments:
1. Throughout, change 'bulk handling' to 'less-than-best-effort'.
2. In the 'Applicability' section - describe the application to new
applications that use non-adaptive protocols (primarily multimedia).
From expereince with customers and IT managers - this type of service is
essential to the deployment of those types of applications.
3. I think the last sentence in section 2 is too strong. No operator
intends to operate their network in a manner in which it is always
congested. Certain applications may be deployable only if they are
willing to take what is available. This means that on networks that are
frequently congested, they may not get much - but then - that's what
this pdb is all about. Basically - I think that this should be a warning
to this effect, rather than a suggestion that the behaviour canot be
used on congested networks.
4. I object to the following rules in section 3.1: 
The network edge must include
a classifier that selects the appropriate BH target group of packets
out of all arriving packets and steers them to a marker which sets
the appropriate DSCP to select a PHB configured as described in
the next section.
Why? In many cases, the customer may chose to premark packets for this
pdb. In that case, why would the ingress need to classify beyond
recognizing the dscp? No MF classification is required. No marking is
required. Rather, it is optional. In fact - I think that this rule
should be clairified for all pdbs, probably in the pdb specification
draft itself. There are many complexities in requiring the ingress node
of a diffserv domain to classify or mark (consider the case of encrypted
packets). Classification and marking (beyond the dscp) should be
optional for all pdbs..
5. Wrt 3.2, last paragraph - the use of 'CS1' as the DSCP for this pdb
is also appealing in its consistency with the interpretaion of 802.1p
user_prioritiy codepoints. In that usage, a codepoint of 1 is also
lesser than a codepoint of 0.

---

From: Simon Leinen <[email-masked]>
Date: 11 Dec 2000 22:31:04 +0100

>>>>> "yb" == Yoram Bernet <[email-masked]> writes:
> previously? I think that it was proposed as draft-mumble-lbe-xx. I
> can't remember the authors, but - one may have been Roland
> Bless. Whoever they were, those authors deserve acknowledgement.

Actually it was a PHB, not a PDB, and the draft suggests that it could
be used for a variety of different PHBs.

        Title           : A Lower Than Best-Effort Per-Hop Behavior
        Author(s)       : R. Bless, K. Wehrle
        Filename        : draft-bless-diffserv-lbe-phb-00.txt
        Pages           : 9
        Date            : 08-Sep-99

http://www-nrg.ee.lbl.gov/diff-serv-arch/msg04311.html
http://www.telematik.informatik.uni-karlsruhe.de/forschung/diffserv/lit/draft-bless-diffserv-lbe-phb-00.txt
-- 
Simon.

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Dec 2000 17:55:51 -0600

I agree that the draft deserves recognition. The reason Kathie and I
wrote our draft was because we don't believe there is any reason
to define a new PHB to support this type of PDB.

As Kathie said today, the LBE name is no better chosen than
BH. Maybe we should call the new PDB "NCT" for Non-Critical Traffic?

  Brian

---

From: Bora Akyol <[email-masked]>
Date: Mon, 11 Dec 2000 16:21:33 -0800

Brian

Despite what was presented today, PDB smells awfully like a service 
definition to me. This is fine by me. Does this mean that we finally are 
starting to consider the services that the PHBs are designed to support?

Bora

At 03:55 PM 12/11/2000, Brian E Carpenter wrote:
> > Archive: 
> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
>
>Archive: 
>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html 
>

Bora Akyol
Pluris
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Dec 2000 18:42:29 -0600

Bora,

My personal view is that an edge to edge service is simply an instance 
of a PDB with the PDB's parameters filled in with specific values.
But that is still not an end to end service. See you in the SLS BOF?

  Brian

---

From: Roland Bless <[email-masked]>
Date: Tue, 12 Dec 2000 09:35:02 +0100

See comments below.

[email-masked] said:
> each night' can be considered a bulk handling task, yet would likely
> not be happy with what is effectively, less than best-effort (LBE)
> service. In addition, I see one of the primary applications of the bh
> pdb in the incremental deployment of aggressive multimedia
> applications (that use non-adaptive UDP). IT managers are reluctant to
> deploy (for example) streaming media over wan links because they
> cannot control the impact of these apps on the wan link resources. One
> way in which we might see these more likely to be deployed is if some
> controlled amount of the multimedia traffic could be given
> priopritized service (appropriate for the media), but any amount
> beyond this would be relegated to the bh pdb (to prevent it from
> seizing network resources required for best-effort. Based on these
> considerations - I would rather  this pdb be called the LBE (less than
> best effort pdb) rather than the bh pdb - I think is is a much more
> descriptive name. 

> can't remember the authors, but - one may have been Roland Bless.
> Whoever they were, those authors deserve acknowledgement. 

Yes, it was draft-bless-diffserv-phb-lbe-00.txt by Klaus Wehrle and me.
We're just rewriting the draft and are going to resubmit it. However,
we decided to change the name to "Limited Effort" (LE) PHB due to the fact that
it's nearly the same behavior as best-effort, but compared to the default 
PHB, it uses resources only up to a defined limit in case of congestion.

There is a very important difference between LE and the proposed BH behavior:
while our definition requires a non-starvation guarantee for the LE BA, BH PDB
does not. Moreover, I see LE and BH as PHBs, because no traffic conditioning
mechanisms are required, no attributes can be specified and no really 
predictable behavior can be given from ingress to egress of a DS domain.
However, this PHB can be implemented by using already existing other
PHB _implementations_ like AF (AF is a very generic PHB).

> As for specific comments: 1. Throughout, change 'bulk handling' to
> 'less-than-best-effort'. 2. In the 'Applicability' section - describe

We propose limited effort.

> deployable only if they are willing to take what is available. This
> means that on networks that are frequently congested, they may not get
> much - but then - that's what this pdb is all about. Basically - I
> think that this should be a warning to this effect, rather than a
> suggestion that the behaviour canot be used on congested networks. 4.

Our definition requires a non-starvation guarantee, therefore it would be
useful even and particularly during congestion. On the other hand LE traffic
can be preempted by best effort traffic, but only down to a configured limit.

> I object to the following rules in section 3.1:  The network edge must
> include a classifier that selects the appropriate BH target group of
> packets out of all arriving packets and steers them to a marker which
> sets the appropriate DSCP to select a PHB configured as described in
> the next section. Why? In many cases, the customer may chose to
> premark packets for this pdb. In that case, why would the ingress need
> to classify beyond recognizing the dscp? No MF classification is

Correct.

> required. No marking is required. Rather, it is optional. In fact - I
> think that this rule should be clairified for all pdbs, probably in
> the pdb specification draft itself. There are many complexities in
> requiring the ingress node of a diffserv domain to classify or mark
> (consider the case of encrypted packets). Classification and marking
> (beyond the dscp) should be optional for all pdbs.. 5. Wrt 3.2, last
> paragraph - the use of 'CS1' as the DSCP for this pdb is also
> appealing in its consistency with the interpretaion of 802.1p

That was mentioned in the BH PDB draft.

Regards,
 Roland

-- 
Roland Bless -- e-Mail: [email-masked]
Institute of Telematics, University of Karlsruhe, F.R. of Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Engesserstr.2 (Bld. 20.50), 1st floor
Phone: +49 721 608-6396 Fax: +49 721 388097

---

From: Roland Bless <[email-masked]>
Date: Tue, 12 Dec 2000 10:29:15 +0100

See comments below.

> to define a new PHB to support this type of PDB.

We don't agree here: 

1. Our formerly proposed LBE PHB (we call it now Limited Effort (LE)
   PHB) is solely defined by PHB mechanisms within a node, 
   no traffic conditioning mechanisms are required. 
   It is however possible to use a specialized AF PHB 
   _implementation_ to obtain the desired behavior. But this is 
   also true for many other PHBs (e.g., EF and CS PHBs). One can 
   surely consider the (old and forthcoming new) EF PHB 
   definition as a special case of the CS 7 PHB, on which the EF PHB 
   _implementation_ can be based upon. In our point of view the EF PHB 
   specification just defines certain requirements and constraints which
   can be applied to the more generic CS PHB definition. If a CS PHB 
   _implementation_ fulfills these particular EF requirements, one gets 
   actually an EF PHB.

2. Packets from excess traffic may be re-marked to LE within a node
   (as proposed in our multicast draft), therefore there is no real
   "edge to edge" behavior in this case.

3. We don't see any "overhead" by this PHB definition. One doesn't need
   new mechanisms for its implementation. For instance, you can use
   a common RED queue for best-effort and LE packets with respective
   different parameter sets, or, alternatively you can use two AF PHBs
   from an AF class, one for BE traffic, one for LE traffic. However,
   how you implement it doesn't really matter, as long as the desired
   and specified LE behavior is met.

> BH. Maybe we should call the new PDB "NCT" for Non-Critical Traffic?

We propose Limited Effort (LE) PHB (draft will follow). However, our
definition has a non-starvation guarantee for the traffic, while BH PDB
allows total starvation of the traffic, resulting in a different
behavior.

Regards,
 Roland

---

From: Kathleen Nichols <[email-masked]>
Date: Tue, 12 Dec 2000 11:23:22 -0800

Roland Bless wrote:
...
> > Whoever they were, those authors deserve acknowledgement.

Yes, as Brian has said and we mentioned this in the WG. This
should have gone into the acks that several people have
requested a "less than best effort" behavior and draft-bless
proposed a PHB. Since we felt it didn't require a new PHB
and that a PDB was the ideal vehicle, we wrote this. And
this was a very quickly written draft and will require editing.

> we decided to change the name to "Limited Effort" (LE) PHB due to the fact that

It's a shame you see it as a PHB...I really like that name,
"limited effort", it would be nice for a PDB. In fact, I
think we should have more "mechanistic" or "behavioral" names
for PHBs, but that's my opinion.

> PHB, it uses resources only up to a defined limit in case of congestion.

Now I'm really confused. This is kind of at the core of diffserv.
The CS PHB group is derived from the old used of IP precedence
and CBQ schedulers. It's been meant from the start that one
could configure PHBs to have "resources only up to a defined
limit in case of congestion". This can even be said of EF. The
notion we heard was for something that uses ONLY the excess
capacity. (Maybe there's a PDB name in there somewhere.)

> while our definition requires a non-starvation guarantee for the LE BA, BH PDB

So we were looking for something that PERMITS starvation, but
doesn't require it. As I said above, I think that non-starvation,
but a possible limit is easily covered by a CS. The earlier
problem with using a CS had been concerns over breaking the
SHOULD to do starvation. I spoke about this yesterday and
Brian posted on this after you proposed your initial draft
some months ago.

> PHB _implementations_ like AF (AF is a very generic PHB).

But we want to describe a behavior across a domain. Both BE and
BH have null traffic conditioning, though there may be classification
required, may be marking, and may even be policing. 
....
> > suggestion that the behaviour canot be used on congested networks. 4.
This is actually Yoram's comments which I partially answered
in the WG meeting and will get to an on-line version. Mostly,
I agree with Yoram, but on the above, I think it's possibly
something about the way we worded things. It's not that you
can not use it on a network that is congested, but the words
were meant only to say that if a network has no capacity to
spare (that isn't being taken up by other types of traffic),
it may not be a good network to deploy this on. So, I don't
believe there is a conflict of philosophy here.

Yoram's going to send some word on applicability, I'm going to
fix some words (particularly the implication that one MUST
classify and mark...we didn't intend to change the intent
of the diffserv architecture as stated in 2475 that this
can be "null", we just got sloppy.), and we'll repost at
some point. Trying to get in other comments as well. 

	Kathie

---

From: Börje Ohlman <[email-masked]>
Date: Tue, 12 Dec 2000 21:31:32 +0100

> BH. Maybe we should call the new PDB "NCT" for Non-Critical Traffic?

I think Non-Critical Traffic is better than both of the previously suggested names. Another alternative which I
find quite intuitive for this type of traffic would be "Background Traffic".

    Börje
--
<pre>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Börje Ohlman               Tel.   +46- 8-508 780 95
KI/ERA/T/NI (Switchlab)    Mobil. +46-70-519 3187
Ericsson Research          Fax.   +46-70-616 3187
Torshamnsgatan 23 (Kista)  Mailto:[email-masked]
S-164 80 Stockholm         WWW:   http://switchlab.ericsson.se/~eraboje/
Sweden                               (only from within Ericsson)
                           Priv.: http://www.abc.se/~m10181

---

From: Kathleen Nichols <[email-masked]>
Date: Wed, 13 Dec 2000 13:45:45 -0800

Mostly a recap of my replies in Monday's WG, but here for the
record, plus other stuff:

> Yoram Bernet wrote:
> necessary pdb. 

It appears from the comments on this that it does meet the
requirement of being useful. Looks like there are other details
to hammer out, but your email (and your quick follow-up to
my request to spell out the application) will help with
the next rev.

> applications of the pdb that extend beyond bulk handling.

So, my simple response on name is "I'm don't care that much" though
I'm kind of leery of "less than best-effort" and of the names
being floated right now, I like Roland's "limited effort" name
he has for his PHB proposal. I think I have to convince him
that most PHB's can be categorized as "limited effort" before
we can steal that name, though... So ... whatever. I could
collect all the suggested names over the next week or two
and do an email poll. Winner gets to host the diffserv mailing
list archive. (Just kidding).

> best effort pdb) rather than the bh pdb - I think is is a much more

This I tried to answer in the meeting. "bulk handling" name wasn't
meant to say this is a PDB to transfer large files/records. For
one thing, I'm philosophically opposed to saying that a
certain PDB is for only one application (in the sense of layer 7,
not in the broad sense of applicability). For another, I used
the name inspired by the US Postal office's bulk mail handling.
(Yes, this is US-centric of me, but I'm from the US and I'm
happy to use another country's designation for this. Or another
name entirely.) More of the notion that you take this when there's
room on the truck. 

> Whoever they were, those authors deserve acknowledgement.

As stated before, yes. I think we saw this as part of a "dialog"
on this topic and had the implicit (wrong) assumption that
everybody "knew this". I think we are/were also hoping that
we might increase the author list as we work on the document
and could try to co-opt those folks to this approach. In any
case, we were remiss.

> From expereince with customers and IT managers - this type of service
> is essential to the deployment of those types of applications.

I plan to insert the part you added. I think there are clearly
both enterprise and ISP applications.

> willing to take what is available. This means that on networks that
> are frequently congested, they may not get much - but then - that's
> what this pdb is all about. Basically - I think that this should be a
> warning to this effect, rather than a suggestion that the behaviour
> canot be used on congested networks.
> 

What you say, "a warning to this effect" rather than a "must not
do this" is what we intended. The original words were (typo and all):

"The BH PDB would not be usefully depolyed in a network which is
congested with non-BH traffic as this indicates no link resources
to spare."

Which we could change to:
"The [foo] PDB is not recommended for networks that are completely
congested with non-[foo] traffic as this indicates no spare
capacity for [foo]."

That, I think, represents the original intent. Does it capture
your objection?

> draft itself. There are many complexities in requiring the ingress
> node of a diffserv domain to classify or mark (consider the case of
> encrypted packets). Classification and marking (beyond the dscp)
> should be optional for all pdbs..

Yes, you are absolutely right about the "optionality" of this. We
didn't mean to rewrite 2475, I think it was just a mindset
we were in at the time. No suggested words right now, I may
go back to 2475 and steal them from there. Ditto for pdb-def.

	Kathie

---

From: Roland Bless <[email-masked]>
Date: Thu, 14 Dec 2000 12:09:00 +0100

> for PHBs, but that's my opinion.

Why is it a shame? Do you have technical reasons why it should not
be a PHB? 

> limit in case of congestion". This can even be said of EF. The

Sure, that is clear. Sorry, my expression was not precise enough and
easily led to misinterpretation. 

> capacity. (Maybe there's a PDB name in there somewhere.)

If we assume that the default PHB is able to use up all residual
resources which are currently not needed by other PHBs, then the
intended behavior is the following (examples were mentioned in the
draft):

1. If best-effort traffic load is less than "residual bandwidth" 
   (unused bandwidth from other PHBs excluding BE and LE), there is
   excess capacity which can be used by the LE PHB.

2. As best-effort traffic load increases, so that there is no residual
   bandwidth left (link is fully/over loaded), it preempts LE traffic,
   but only up to a defined limit. Particularly, permitted LE traffic
   will not exceed this limit in this case, independent of what the
   current LE load is.

The results should be: 
A) If resources are fully used, BE traffic is protected from LE 
   traffic, because the LE PHB cannot use more resources than 
   defined by the limit.
B) LE PHB can use excess capacity which is not used by the
   default PHB (without LE traffic link is not fully loaded).

IMHO even in congestion situations, one should be able to get some
LE packets through. Therefore, we think that starvation is even
not good for this low priority class. But if an administrator
decides to set the configurable limit to 0, then starvation is
also permitted.
 
> Brian posted on this after you proposed your initial draft

Naturally, you can use a (lower priority than CS0) CS or 
two AF PHBs (one for LE, one for default PHB) for _implementation_.
The fact that you can also use a CS7 for EF PHB implementation does
IMHO not make the EF PHB definition unnecessary and the same argument
applies to the LE PHB definition. It's simply a more specific PHB than
the more generic CS or AF PHBs.

> required, may be marking, and may even be policing. 

Yes, but we want to describe a forwarding behavior. The origin
of the LE PHB was in the context of our proposed multicast
solution: if a new branch is grafted to a multicast tree by an existing
mc-routing protocol, packets are re-marked to the LE PHB within a multicast
DS node as long as no reservation was set up (by whatever mechanism) for 
the new branch. In order to protect ordinary BE users from a possible flood
of re-marked packets which arrive with a better PHB, we defined this LE PHB.
In this case, a source of LE packets is possibly located within a domain.

Naturally, you will be able to do initial classification and marking
or even policing, although I believe that often applications will do
a pre-marking for LE.

> believe there is a conflict of philosophy here.

In our definition, the LE PHB will be useful even in these 
congested networks, if you set the limit > 0.

Regards,
 Roland

---

From: Kathleen Nichols <[email-masked]>
Date: Thu, 21 Dec 2000 11:49:11 -0800

Roland Bless wrote:
> > "limited effort"
...
> Why is it a shame? 

I expressed it that way to say that I thought that would make
a good alternate name for the BH PDB. This was not a technical
comment. It doesn't need to be pursued.

...

I omitted some of our discussion, but I think these two
paragraphs below show we are saying the same thing. That
you MAY starve, but are not REQUIRED to starve: this is
up to the network administrator. Writing the PDB to *permit*
starvation was critical for two reasons: 1) we heard several
operators express a desire to do that and 2) this is very
different from the current notion of "best effort". Your
words seem, to me, to say you think starvation is a bad idea,
but to leave it up to the administrator. This is the same as
the BH PDB, except we try not to express an opinion on whether
starvation is "good" or "bad".

...
> In this case, a source of LE packets is possibly located within a domain.

Our intent is for a more general PDB to be used as needed. I would
suggest that some experimentation with your multicast approach
would be in order first. 

It's possible that the internet industry would reach a point where
some of the CS PHBs, or some other DSCP marking, might be "default"
configured for use by such PDBs as "best effort", "bulk handling",
"network critical", etc. But it would be best to get some deployment
experience and see what is useful first.

Further, the notion of the amount of resource to allocate to something
which is below best effort seems, arguably, to be best done on a network
or domain basis.

	regards,
		Kathie

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 21 Dec 2000 20:22:42 +0000 (GMT)

On Thu, 21 Dec 2000, Kathleen Nichols wrote:

> It's a shame you see [BH] as a PHB...I really like that name,
> "limited effort"

I move that we rename the EF PHB 'unlimited effort', as a reflection
of the time and resources expended on it.

> comment. It doesn't need to be pursued.

This is not a technical comment, and does not need to be pursued.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>