Re: Iq/Ix-controlled IP byte-rate policing (based on H.248.53 tman)

<adding megaco again because H.248.53 should be discussed on that list>
 
Thomas,
think we are not far away from each other.
Two comments:
 
>I only clarify that the bitrate shall include all layers from IP upward
 
H.248.53 cl. 9 is already fairly precise on that aspect. For instance,
you may just refer to Equation (9.4.3) (-> 

NOTE 1 - The IP sustainable byte rate Rs relates to IP packets, i.e.
exclusive lower protocol layers.

)
 
Does you text "all layers from IP upward" include or exclude the IP
header?
 
2nd: ... the very complex two-stage algorithm for traffic policying ...
 
Which complexity do you got in mind? The policy enforcement or policy
decision complexity?
The policy enforcement side (H.248 MG) is not really complex (if GBRA
... Y.1221).
The policy decision side: right, the challenge is the underlying traffic
model for deriving correspondent traffic parameters.
However, IMS is designed for all kind of applications, which makes it
difficult to exclude certain traffic policer types per se.
 
Regards,
Albrecht
 
 



________________________________

	From: 3GPP_TSG_CT_WG3 - Core Network and Terminals WG 3
[mailto:[email protected]] On Behalf Of Belling, Thomas (NSN
- DE/Munich)
	Sent: Donnerstag, 8. Oktober 2009 11:49
	To: [email protected]
	Subject: Re: Iq/Ix-controlled IP byte-rate policing (based on
H.248.53 tman)
	
	
	Hi Albrecht:
	 
	<removing ietf megaco becaue I am not a member of this list>
	 
	some quotations from H.248.53
	 
	 
	9 Deriving policy enforcement point parameters from parameters
of traffic management

	and other packages

	In this clause, relationships between the generic traffic
parameters, as defined in clauses 6 to 8, and

	specific traffic policers are provided. Such a traffic policer
could be part of a general PEP.

	Parameter mapping recommendations are required due to: 

	 

	 

	TISPAN Traffic Management Packages

	(This appendix does not form an integral part of this
Recommendation)

	This Appendix contains the Traffic Management package version 1,
which is based on a copy of the

	original version of the ETSI TISPAN Traffic Management package
(see [b-ETSI TS 102 333]).

	This Appendix is for the information of implementers.

	... 

	II.1.6 Procedures

	 ...

	 

	 The interpretation of these properties (i.e. pdr, sdr, dvt and
mbs) is dependent on the type of

	transport is associated with the H.248 Terminations, for
example, ATM or IP. The package makes

	no assumptions as to what layers (e.g. layer 2 or layer 3) are
included in the properties and therefore

	it is recommended to include the exact interpretations in a
profile, e.g. based on parameter mapping

	guidelines according clause 9. 

	 

	Although this is not really related to the core of my discussion
paper, the text in the Introduction to the traffic management package
v1  in H.248.53 does not fully fit to your explanations. Perhaps ITU-T
should consider updating this a bit.

	 

	But I also base my analysis on Clause 9 in the lack of other
information, although this is mentioned only as an example in tman v1
(as used in 3GPP).

	Clause 9 considers the relationship to a couple of diffrent
algorithms. for IP these are algorithms based on  Y.1221 or RFC 2216. 

	I do not believe we should mandate a gateway to apply a
particular leacky bucket algorithm amd select one particulat of those
references. In particular, I have some concerns about the very complex
two-stage algorithm for traffic policying described in Y.1221. We should
not mandate a gateway to use this.

	I certainly also do not intend to invent semantics that are in
conflict with Clause 9. My analysis rather intended to derive more
information about the semantics from this clause, which strictly
speaking also only provides indirect clues about the semantics by
clatifying how the parameters could be used at a gateway assuming the
gateway is using this or that algorithm.

	If you look into normative changes I propose you will find that
I only clarify that the bitrate shall include all layers from IP upward,
and that ithe sustainable bit rate shall be calculated averaging over a
time that is sufficiently long to average out effect of bursts and
jitter.

	In doing so, I only follow recommendations given in H.248.53 for
tman v1: it is recommended to include the exact interpretations in a
profile

	Do you have concerns with these explanations? 

	 

	 

	 

	
	
________________________________

	From: ext Schwarz Albrecht
[mailto:[email protected]] 
	Sent: Thursday, October 08, 2009 9:00 AM
	To: Belling, Thomas (NSN - DE/Munich);
[email protected]
	Cc: megaco; [email protected]
	Subject: Iq/Ix-controlled IP byte-rate policing (based on
H.248.53 tman)
	
	
	Hi Thomas,
	just read your 091251:
	 
	
http://www.3gpp.org/ftp/tsg%5Fct/WG3%5Finterworking%5Fex%2DCN3/TSGC3_55_
Phoenix/Doc/C3-091251.zip
<http://www.3gpp.org/ftp/tsg%5Fct/WG3%5Finterworking%5Fex%2DCN3/TSGC3_55
_Phoenix/Doc/C3-091251.zip> 
	 
	Two comments/concerns:

	1.	Don't refer ETSI TISPAN TS 102 333!
		because
		- tman v1 was transferred to ITU-T some years ago,
H.248.53 is thus the only relevant reference for tman
		- there isn't any IANA registry anymore for the original
ETSI package, thus TS 102 333 is really irrelevant in your contribution 
	2.	Semantic of tman properties
		=> cl. 9/H.248.53 is normative, it's not just examples
of policer types
		=> Iq/Ix got to select a particular policing algorithm
(which must be equivalent to cl. 9), or leave it open and then
implicitly refer to cl. 9 (i.e., either a Y.1221 or RFC 2216 policer for
IP byte-rate policing)
		=> I'm concerned that you want introduce a 2nd semantic
for tman properties when reading "Interpreting sdr and pdr at the
gateway as recommended in Clause 9 of H.248.53 requires ...".
		Again, cl. 9 mandates parameter mappings between H.248
elements and policer types. 
		If you are unhappy with the tman semantics, then
contribute against H.248.53 itself, but profile-specific package
semantics would be the wrong approach in my opinion.

	 
	Note: reference for tman is H.248.53 (03/09), which supersedes
H.248.53 (06/08), - but H.248.53 (03/09) is unfortunately not yet
published by ITU-T. 
	 
	Regards,
	Albrecht

_______________________________________________
Megaco mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/megaco