Subject: draft-ietf-issll-rsvp-cap-01.txt

From: "Yoram Bernet" <[email-masked]>
Date: Wed, 13 Dec 2000 12:04:13 -0800

Hamid:

Please pardon my delay in raising these issues. But - here goes:

I am struggling with the real application of the  hcap object. I believe
that it is useful, but - its exact value eludes me. For example, in
section 3.1, you state that: 

"This information can help the network element to decide whether or not
a DCLASS object must be added in a RSVP message for the flow."

and:

"The network edge router will then know that the upstream node/end host
does not require a DCLASS object."

I think that this is presented as the justification for the hcap object,
yet - I don't think that this is really a good justification. Why not
just always add a DCLASS object to RSVP messages? What is the cost of
doing so? What is the difference (in terms of the results) between
always adding the DCLASS object and selectively adding the DCLASS
object? I think that there is no difference - consider the following:

1. No HCAP:
a. Marking capable hosts - DCLASS sent, hosts mark.
b. Non-marking capable hosts - DCLAS sent, hosts do not mark.

2. HCAP:
a. Marking capable hosts - DCLASS sent, hosts mark.
b. Non-marking capable hosts - no DCLASS sent, hosts do not mark.

So - while the hcap object does affect whether or not a DCLASS is sent,
it doesn't seem to effect whether the host actually marks or not. So -
the only value of the hcap object here, is to save the network device
the trouble of sending a DCLASS that would be ignored. But then -
sending a DCLASS object seems to be pretty low cost behaviour.

Similarly, in 3.2, I think that the hcap object is presented as nothing
more than an optimization and a debatable one, at that. The optimization
is to prevent a network element from generating a DCLASS if it is going
to be ignored. The value of this optimization is debatable because the
cost of processing hcap objects and storing related state is not clearly
worth the cost savings of not 'just sending a DCLASS, always'.

I think that there might be a real value to the HCAP object. But - I
think that it is less in telling a network element when to send a DCLASS
and when not to and more in helping a network element to validate the
DSCP provided by hosts. For example - it may be the case that at the
network element, traffic arrives from a variety of hosts. Some of this
traffic is marked purposely, by DCLASS aware hosts. Other is marked
arbitrarily, by 'rogue' hosts. Perhaps this is the utility of the HCAP
object. 

In section 5, it states that the network edge must be manually
configured to either send a DCLASS object, install a filter to cause
marking for a flow, or both. There is a third option - do neither. For
example, consider the ingress router to a diffserv network that offers a
simple static SLA (of the form customer on interfgace A gets to send 1
Mbps of traffic marked EF). In the simplest case, there is no need to
send a DCLASS and no need to mark on behalf of the customer. The
customer simply uses whatever strategies are appropriate for marking and
the provider simply polices to enforce the SLA.

Yoram