[Diffserv] comments on the bulk handling draft

["Yoram Bernet" <[e-mail]>]

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.