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

From: "Yoram Bernet" <[email-masked]>
Date: Tue, 19 Dec 2000 09:01:23 -0800

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

[Yoram Bernet] OK - noted. I agree that it should not be limited to
host/router interaction.  

2. The intent of the D-mark bit is not just the scenarios you described.

[Yoram Bernet]  Hamid - I agree with you entirely. The problem is that
these are the scenarios that *you* described, right out of the draft and
frankly, in and of themselves, they do not provide any justification for
the CAP. 

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.

[Yoram Bernet]  So now (in this e-mail) you have added a discussion of
the functionality that might justify the CAP object. As I stated at the
meeting, this issue is much more about filters and marking and so forth
and that's what needs to be talked about. Instead, your draft focuses
exclusively on whether or not a DCLASS object should be sent. The thing
is that the real usage of the cap object with respect to marking, is
quite complicated. When you talk about installing filters - what filters
are these exactly? What remarking is done in different scenarios? Is
marking really the issue or is it policing? 
 
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. 

[Yoram Bernet] I'm not asking you to capture 'other possible usages'.
I'm asking you to think through the one you already presented more
thoroughly and to justify it. 

My suggestions are:
1. Limit the draft to be nothing more than a definition of the CAP
object.
2. Issue separate draft(s) that each describe a particular use of the
object (e.g. for enabling a host to tell the network that it is capable
of marking) and that clearly explain what the network will do with the
information that is conveyed to it by the CAP object. If you can't
clearly articulate what the network would do with the information in the
CAP object and why it is able to do something better with that
information than it would without it, then that application of the CAP
object can't be justified. I've done a lot of thinking about the
application that you suggest for the CAP object. I think that it's an
important issue to think through. I suspect that it is useful
information, but can't quite articulate yet how it would be used. I've
done a bit of writing on it, but nothing that is ready for consumption
yet. As soon as it is, I will post it to the list.

Thanx for your comments anyways. 
cheers 
-Hamid 

[Yoram Bernet] Regards,
Yoram

-----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