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

From: "Hamid Syed" <[email-masked]>
Date: Fri, 12 Jan 2001 15:28:06 -0500

comments on line

> -----Original Message-----
> From:	Yoram Bernet [SMTP:[email-masked]]
> Sent:	Tuesday, December 19, 2000 12:01 PM
> To:	Syed, Hamid [WDLN2:AN22:EXCH]
> Cc:	issll
> Subject:	RE: draft-ietf-issll-rsvp-cap-01.txt
> 
> 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.
	[Syed, Hamid [WDLN2:AN22:EXCH]]  Well.. I do not totally disagree
with your suggestions. I guess we had some kind of WG agreement on these
issues during the IETF49 meeting. We also did agree on some action items. I
am waiting for the meeting minutes to be relaesed by the chair. 
	[Syed, Hamid [WDLN2:AN22:EXCH]]  thanx ...Hamid
> 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 
>