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

From: "Hamid Syed" <[email-masked]>
Date: Mon, 18 Dec 2000 10:27:27 -0500

Yoram,

Couple of clearifications here..

1. The object is defined as (Capability Object, CAP) NOT "hcap". This means
that it must not be misunderstood as an object which does interact between
the hosts and the edge routers for marking only

2. The intent of the D-mark bit is not just the scenarios you described. I
re-phrase your scenarioes (though I still believe that do not limit CAP
object just for marking or just between end host and edge of the network) 
	1. No CAP:
	a. Marking capable hosts - DCLASS sent, hosts mark.
	b. Non-marking capable hosts - DCLAS sent, hosts do not mark.

	2. CAP:
	a. Marking capable hosts - DCLASS sent, hosts mark. The edge router
assumes a marked traffic arrival and may be just have to install policing
rules 
	b. Non-marking capable hosts - no DCLASS sent, hosts do not mark.
The edge router have to install install filters to mark the traffic from the
end host. So the capability object really provides more intelligent
decisions made at the edge device or at the downstream nodes on RSVP PATH
messages.

Now, as i mentioned before (and also in the draft) that D-mark is an initial
usage case for the CAP object. Other applications/utilities are really out
there and I agree with you that other possible usages of the CAP object must
be captured as well. I would welcome any suggestion in this regard. 

Thanx for your comments anyways.

cheers
-Hamid

> -----Original Message-----
> From:	Yoram Bernet [SMTP:[email-masked]]
> Sent:	Wednesday, December 13, 2000 3:04 PM
> To:	Syed, Hamid [WDLN2:AN22:EXCH]
> Cc:	issll
> Subject:	draft-ietf-issll-rsvp-cap-01.txt
> 
> 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
> 
>