[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Title: RE: Ix transcoding stage 2 - a new compromise
Hi Albrecht,
 
> Does you text "all layers from IP upward" include or exclude the IP header?
It is supposed to include the IP layer, but I can use a clearer formulation.
 
> Which complexity do you got in mind? The policy enforcement or policy decision complexity?
Actually, I had both the complexity at the controller and the gateway in mind

> The policy enforcement side (H.248 MG) is not really complex (if GBRA ... Y.1221).
You require two queues instead of one. That is the additional complexity I see.
 
Thomas
 
From: ext Schwarz Albrecht [mailto:Albrecht.Schwarz at alcatel-lucent.de]
Sent: Monday, October 12, 2009 12:33 PM
To: Belling, Thomas (NSN - DE/Munich); 3GPP_TSG_CT_WG3 at LIST.ETSI.ORG
Cc: megaco
Subject: 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:3GPP_TSG_CT_WG3 at LIST.ETSI.ORG] On Behalf Of Belling, Thomas (NSN - DE/Munich)
Sent: Donnerstag, 8. Oktober 2009 11:49
To: 3GPP_TSG_CT_WG3 at LIST.ETSI.ORG
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:Albrecht.Schwarz at alcatel-lucent.de]
Sent: Thursday, October 08, 2009 9:00 AM
To: Belling, Thomas (NSN - DE/Munich); 3GPP_TSG_CT_WG3 at LIST.ETSI.ORG
Cc: megaco; simao.campos at itu.int
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
 
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