Subject: [Tsvwg] draft-ietf-tsvwg-admitted-realtime-dscp-05

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 15 Jan 2009 10:24:21 +0200

By coincident I ran into the following draft: 
http://tools.ietf.org/html/draft-ietf-tsvwg-admitted-realtime-dscp-05

Section 2.3 says: 

"
   On the point of what protocols and procedures are required for
   authentication, authorization, and capacity admission, we note that
   clear standards do not at this time exist for bandwidth brokers, NSIS
   has not at this time been finalized and in any event is limited to
   unicast sessions, and that RSVP has been standardized and has the
   relevant services.  We therefore recommend the use of RSVP at the
   UNI.  Procedures at the NNI are business matters to be discussed
   between the relevant networks, and are recommended but not required.
"

and the IANA consideration section says:

"
   This traffic class requires the use of capacity admission such as
   RSVP services together with AAA services at the User/Network
   Interface (UNI); the use of such services at the NNI is at the option
   of the interconnected networks.
"

The text (to me) sounds like that this DSCP essentially requires RSVP to be
implemented in order to get this to work. This is IMHO not correct. 

To give you one other example of a standardized mechanism that would do the
job: Rx/Gx (3GPP)

Ciao
Hannes

---

From: ken carlberg <[email-masked]>
Date: Thu, 15 Jan 2009 09:59:48 -0300

I'm afraid you've lost me.  The words "recommend" and "such as" from  
the cited text below doesn't IMO come close to giving an impression  
of "essentially requires".  The cited text makes an observation about  
the work from NSIS, with (my) assumption that the authors choose to  
discuss the topic within the context of IETF signaling protocols.

If you would like to advocate the integration of Rx/Gx (3GPP) with  
the work at hand, perhaps it may be more helpful to describe this  
suggested interaction in more detail with suggested text.

cheers,

-ken

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 15 Jan 2009 15:04:58 +0200

Hi Ken, 

I would like the document not to talk about this at all. 
I don't know why it has to. 

Ciao
Hannes 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext ken carlberg
>Sent: 15 January, 2009 15:00
>To: Hannes Tschofenig
>Cc: [email-masked]
>Subject: Re: [Tsvwg] draft-ietf-tsvwg-admitted-realtime-dscp-05
>
>I'm afraid you've lost me.  The words "recommend" and "such 
>as" from the cited text below doesn't IMO come close to giving 
>an impression of "essentially requires".  The cited text makes 
>an observation about the work from NSIS, with (my) assumption 
>that the authors choose to discuss the topic within the 
>context of IETF signaling protocols.
>
>If you would like to advocate the integration of Rx/Gx (3GPP) 
>with the work at hand, perhaps it may be more helpful to 
>describe this suggested interaction in more detail with suggested text.
>
>cheers,
>
>-ken
>
>
>> The text (to me) sounds like that this DSCP essentially 
>requires RSVP 
>> to be implemented in order to get this to work. This is IMHO not 
>> correct.
>>

---

From: ken carlberg <[email-masked]>
Date: Thu, 15 Jan 2009 10:13:21 -0300

ok, but could you make a stronger case as for why?  the cited text  
presents context and recommendations with what we have on hand now,  
but doesn't make a hard requirement of MUST.  if someone else comes  
along later and defines a better widget, or simply another way of  
accomplishing the fundamental objectives of the draft with a  
different signaling protocol....great, and please let's encourage  
them to tell "us" how.

cheers,

-ken

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 15 Jan 2009 15:19:35 +0200

Creating the perception that only RSVP can be used to provide the
required functionality does not reflect reality. 
If one wants to be fair then this has to be stated. When protocols are
discussed then it would be fair to say that there isn't only RSVP and
NSIS. 

Does this make sense to you? 

Ciao
Hannes

>From: ext ken carlberg [mailto:[email-masked]] 
>Sent: 15 January, 2009 15:13
>To: Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: Hannes Tschofenig; [email-masked]
>ok, but could you make a stronger case as for why?  the cited 
>text presents context and recommendations with what we have on 
>hand now, but doesn't make a hard requirement of MUST.  if 
>someone else comes along later and defines a better widget, or 
>simply another way of accomplishing the fundamental objectives 
>of the draft with a different signaling protocol....great, and 
>please let's encourage them to tell "us" how.
>
>cheers,
>
>-ken
>
>
>>> From: [email-masked] [mailto:[email-masked]] On 
>>> Behalf Of ext ken carlberg
>as" from 
>>>>    clear standards do not at this time exist for bandwidth 
>brokers, 
>>>> NSIS
>>>> To give you one other example of a standardized mechanism 
>that would 
>>>> do the
>>>> job: Rx/Gx (3GPP)
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>
>>>
>
>

---

From: ken carlberg <[email-masked]>
Date: Thu, 15 Jan 2009 10:34:29 -0300

no, and this discussion is becoming circular.  I go back to the  
preciseness of the language in the text of the draft that discusses  
RSVP as a recommendation, not a requirement in the form of a must.

to follow your line of reasoning, we would need to go back to all  
protocols that interact with SIP and say "please consider other  
protocols like H.323, and perform the interaction in the following  
way (blah, blah, blah)", since there are others means to signal the  
establishment of sessions.

the two of us seem to agree to disagree.

kindest regards,

-ken

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 15 Jan 2009 18:36:52 +0200

Hi Ken, 

Don't give up so quickly. I know, you are not the author of the document
but let us look at the text in detail and my proposal for change: 

2.3.  Recommendations on implementation of an Admitted Telephony Service
      Class

   It is the belief of the authors that either PHB implementation
   described in Section 2.1, if coupled with adequate AAA and capacity
   admission procedures as described in Section 2.2, are sufficient to
   provide the services required for an Admitted Telephony service
   class.

CHANGE PROPOSAL:
"
   It is the belief of the working group that either PHB implementation
   described in Section 2.1, if coupled with adequate AAA and capacity
   admission procedures as described in Section 2.2, are sufficient to
   provide the services required for an Admitted Telephony service
   class.
"

REASON: I hope the working group believes it as well and not only the
authors. 

   If preemption is required, as described in section 2.3.5.2 of
   [RFC4542], this provides the tools for carrying out the preemption.
   If preemption is not in view, or if used in addition to preemptive
   services, the application of different thresholds depending on call
   precedence has the effect of improving the probability of call
   completion by admitting preferred calls at a time that other calls
   are being refused.  Routine and priority traffic can be admitted
   using the same DSCP value, as the choice of which calls are admitted
   is handled in the admission procedure executed in the control plane,
   not the policing of the data plane.

CHANGE PROPOSAL:

"
As previously noted, the PHB implementation requires the QoS resource
request triggered from the end device (UNI interface) and the subscriber
to be authenticated and authorized. Different mechanisms are available
for conveying the QoS information and also for performing the
authentication and authorization. This document does not mandate a
specific protocol to be used. 
"

REASON: The discussion regarding NSIS vs. RSVP is irrelevant for this
document. The recommendation for RSVP is not necessary in order to
accomplish the overall goal of this document. 

5.  Security Considerations

   A major requirement of this service is effective use of a signaling
   protocol such as RSVP, with the capabilities to identify its user
   either as an individual or as a member of some corporate entity, and
   assert a policy such as "routine" or "priority".

   This capability, one has to believe, will be abused by script kiddies
   and others if the proof of identity is not adequately strong or if
   policies are written or implemented improperly by the carriers.  This
   goes without saying, but this section is here for it to be said...

A question: Is there really a (major) requirement to identity the user
as individual or as a member of some corporate entity? I would have said
that there are authentication and authorization requirement but not
necessarily regarding the membership. 

4.  IANA Considerations

   This note requests that IANA assign a DSCP value to a second EF
   traffic class consistent with [RFC3246] and [RFC3247] in the
   "Differentiated Services Field Codepoints" registry.  It implements
   the Telephony Service Class described in [RFC4594] at lower speeds
   and is included in the Real Time Treatment Aggregate [RFC5127] at
   higher speeds.  The recommended value for the code point is 101100,
   paralleling the EF code point, which is 101110.  The code point
   should be referred to as VOICE-ADMIT.

SUGGESTION: Delete last paragraph as it does not add anything beyond
what was said in the document.

Ciao
Hannes

>Sent: 15 January, 2009 15:34
>no, and this discussion is becoming circular.  I go back to 
>the preciseness of the language in the text of the draft that 
>discusses RSVP as a recommendation, not a requirement in the 
>form of a must.
>
>to follow your line of reasoning, we would need to go back to 
>all protocols that interact with SIP and say "please consider 
>other protocols like H.323, and perform the interaction in the 
>following way (blah, blah, blah)", since there are others 
>means to signal the establishment of sessions.
>
>>>>>>    has not at this time been finalized and in any event 
>is limited 
>>>>>> to
>>>>>>    Interface (UNI); the use of such services at the NNI 
>is at the 
>>>>>> option

---

From: ken carlberg <[email-masked]>
Date: Thu, 15 Jan 2009 17:40:25 -0300

Hannes,

I always appreciate your determination, but I'm just not convinced by  
your arguments :-)....more below...

> REASON: I hope the working group believes it as well and not only the

fine and reasonable change from my perspective.

> accomplish the overall goal of this document.

the problem is that you are leaving out the *critical* term of  
capacity admission in your proposed text.  And yes, take that out,  
and I have no qualms in removing references/text concerning NSIS and  
RSVP.  But, capacity admission has to be there...its part of the  
foundation for the draft in the first place.

While the term QoS tends to imply the probable use of capacity  
admission, its too broad a term with respect to how you choose to use  
it above.  For instance, I can configure filters for a CBQ router to  
alter the QoS for certain types of flow and thus influence the QoS  
received by those flows, but that effort does not necessarily deal  
with capacity admission.

> necessarily regarding the membership.

I don't have a strong opinion on this, so I suggest one of the co- 
authors chime in on this.

> what was said in the document.

let's not for now :-)

cheers,

-ken

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 15 Jan 2009 22:46:35 +0200

Hi Ken, 

See below. 

>Hannes,
>
>I always appreciate your determination, but I'm just not 
>convinced by your arguments :-)....more below...
>
>> Hi Ken,
>>
>> Don't give up so quickly. I know, you are not the author of the 
>> document but let us look at the text in detail and my proposal for 
>> change:
>>
>>
>> request triggered from the end device (UNI interface) and the 
>> subscriber to be authenticated and authorized. Different mechanisms 
>> are available for conveying the QoS information and also for 
>> performing the authentication and authorization. This document does 
>> not mandate a specific protocol to be used.
>> "
>>
>capacity admission in your proposed text.  And yes, take that 
>out, and I have no qualms in removing references/text 
>concerning NSIS and RSVP.  But, capacity admission has to be 
>there...its part of the foundation for the draft in the first place.

That's in the previous paragraph. I believe that there is no reason to
repeat it again. 

>admission, its too broad a term with respect to how you choose 
>to use it above.  For instance, I can configure filters for a 
>CBQ router to alter the QoS for certain types of flow and thus 
>influence the QoS received by those flows, but that effort 
>does not necessarily deal with capacity admission.

That's true. Signaling the QoS parameters does not imply capacity
admission control. 
However, I believe it is covered by the previous paragraph already. 

>> as individual or as a member of some corporate entity? I would have 
>> said that there are authentication and authorization requirement but 
>> not necessarily regarding the membership.
>
>I don't have a strong opinion on this, so I suggest one of the 
>co- authors chime in on this.
>
>> 4.  IANA Considerations
>>

Then, I suggest to remove the RSVP part. 

Ciao
Hannes

---

From: "Rodrig, Benny (Benny)" <[email-masked]>
Date: Thu, 15 Jan 2009 17:09:05 -0500

Hi Ken,

Hannes's point does make sense to me, that the language of the 2nd
paragraph of section 2.3 is rather strong and can give the wrong
impression that RSVP in particular, and not just good capacity admission
in general, is necessary for this service.  

Instead, the 1st paragraph of section 2.3 can perhaps be changed along
the lines of the following text:

Support for an Admitted Telephony service class requires, at the UNI,
adequate AAA and capacity admission procedures as described in Section
2.2. This document does not mandate a specific protocol to be used. It
is the belief of the working group that either PHB implementation
described in Section 2.1 is sufficient to provide the services required,
if coupled with such adequate AAA and capacity admission procedures.
Procedures at the NNI are business matters to be discussed between the
relevant networks, and are recommended but not required.

Benny 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Thursday, January 15, 2009 3:47 PM
To: ext ken carlberg
Cc: [email-masked]
Subject: Re: [Tsvwg] draft-ietf-tsvwg-admitted-realtime-dscp-05

Hi Ken, 

See below. 

>the problem is that you are leaving out the *critical* term of capacity

>admission in your proposed text.  And yes, take that out, and I have no

>qualms in removing references/text concerning NSIS and RSVP.  But, 
>capacity admission has to be there...its part of the foundation for the

>draft in the first place.

>received by those flows, but that effort does not necessarily deal with

>capacity admission.

Ciao
Hannes