Subject: [Tsvwg] Comments about draft-karagiannis-ru-pdb-02

From: Jorge Andrés Colás <[email-masked]>
Date: Wed, 20 Sep 2006 11:30:30 +0200

Hi Georgios,

I have reviewed the RU-PDB draft (draft-karagiannis-ru-pdb-02), and I 
have some comments about it:

- I get somehow confused while reading the example (section 7) which is 
about the usage of the RU-PDB mechanism jointly with the ECN mechanism 
to have a complete solution to avoid network congestion. I think it is a 
very good example, but until that point in the text nothing was said 
about this usage in collaboration with ECN. I think you should say 
something about this possible usage (which makes a lot of sense) in the 
applicability section (1.1). I have in mind the view that ECN assumes a 
network with no admission control mechanism (i.e. a typical IP network), 
while the mechanism you propose allows ECN to work in an environment 
with admission control mechanisms by using them (with RU notifications 
to the CAC) before degrading active calls/flows with ECN echos. Do you 
agree?

- I see the text in section 3.2 a bit confusing. I would split the 
functionalities a bit more, e.g.: 1) metering, 2) policing, 3) 
classification and marking, 4) treatment; at least, for the explanation. 
In my view, the usage of different virtual queues is 'treatment' instead 
of 'classification', the remarking of packets is 'classification and 
marking' instead of 'policing', which is the comparison of the 
measurement with the thresholds, etc.

- Reference to RFC3168 (pag. 7) is not included in reference sections.

- For the example, I think it is valid for any DiffServ-based IP 
network, thus I wouldn't restrict it to 'mobile systems' or wired parts 
of cellular systems, as you say in the text.

Hope this helps!
Regards,
Jorge

-- 
Jorge Andrés Colás
Telefónica I+D
Emilio Vargas, 6
28043 - Madrid (España)
 
E-mail: [email-masked]
Tel. +34 91 337 39 28
Fax. +34 91 510 33 08

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 22 Sep 2006 12:29:10 +0200

Hi Jorge

Thank you for your comments!
Please see inline! 

> -----Original Message-----
> From: Jorge Andrés Colás [mailto:[email-masked]] 
> Sent: woensdag 20 september 2006 11:31
> To: [email-masked]
> Subject: [Tsvwg] Comments about draft-karagiannis-ru-pdb-02

> I have reviewed the RU-PDB draft (draft-karagiannis-ru-pdb-02), 
> and I have some comments about it:

> - I get somehow confused while reading the example (section 7) 
> which is about the usage of the RU-PDB mechanism jointly with 
> the ECN mechanism to have a complete solution to avoid network 
> congestion. I think it is a very good example, but until that 
> point in the text nothing was said about this usage in 
> collaboration with ECN. I think you should say something about 
> this possible usage (which makes a lot of sense) in the 
> applicability section (1.1). I have in mind the view that 
> ECN assumes a network with no admission control mechanism 
> (i.e. a typical IP network), while the mechanism you propose 
> allows ECN to work in an environment with admission control 
> mechanisms by using them (with RU notifications to the CAC) 
> before degrading active calls/flows with ECN echos. Do you agree?

Georgios: Yes, I agree with your observations. 
We will include such details into the Applicabiliy section (1.1). 

Regarding the second observation, we are using the end-to-end 
ECN solution in combination with the DSCP based RU-PDB mechanism, 
to support any streaming application, e.g., video, that use a rate 
adaptive coding that can adapt the bandwidth but for 
a feasible service quality it requires a minimum bandwidth. 

The minimum bandwidth has to be allocated because otherwise 
the service is useless. The minimum bandwidth is allocated by 
using the DSCP based RU-PDB mechaninsm in combination with 
the CAC functionality.

If the network has more capacity it can utilize that and give 
the enduser a higher quality with better end user experiece. 
The end to end ECN method cvan be used to monitor if the network has 
more capacity. Note that in this case the RU-PDB has to 
DSCP marking (and not ECN marking) for the RU notifications. 
This is because an interoperability 
problem will occur between the end-to-end ECN and the RU PDB marking.

We will include such details in the applicability section.

> - I see the text in section 3.2 a bit confusing. I would split 
> the functionalities a bit more, e.g.: 1) metering, 2) policing, 
> 3) classification and marking, 4) treatment; at least, for 
> the explanation. 
> In my view, the usage of different virtual queues is 
> 'treatment' instead of 'classification', the remarking of 
> packets is 'classification and marking' instead of 'policing', 
> which is the comparison of the measurement with the thresholds, etc.

Georgios: Agree, we will work out your comments!

> - Reference to RFC3168 (pag. 7) is not included in reference sections.

Georgios: Agree, we will do that!

> - For the example, I think it is valid for any DiffServ-based IP network, 
> thus I wouldn't restrict it to 'mobile systems' or wired parts 

Georgios: Agree with you, but compared to other solutions this one is 
very useful in the situation that streaming applications are supported 
that use rate adaptive media codecs. 
Such solutions can for example be applied in the IP Multimedia Subsystem
(IMS)!

Best regards,
Georgios