Subject: RE: [Tsvwg] Comments on Ru PDB draft (from michael)

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 9 Oct 2006 12:09:29 +0200

Hi Michael

Thank you very much for your comments!
Please see my remarks in line!

> -----Original Message-----
> From: Michael Menth [mailto:[email-masked]] 
> Sent: vrijdag 29 september 2006 13:02
> To: [email-masked]
> Subject: [Tsvwg] Comments on Ru PDB draft
> 
> Hi,
> 
> I browsed through your draft.
> http://www.ietf.org/internet-drafts/draft-karagiannis-ru-pdb-02.txt
> 
> Here are my comments.
> * What does TCS stand for?

Please note that the section title conforms 
to the guidelines given in RFC3086,
see Section 7.1.2 in:
http://www.ietf.org/rfc/rfc3086.txt?number=3086

TCS is refering to Traffic conditioning specification

> * I found the draft difficult to understand although the 
> contents is actually simple: interior mark packets if the 
> current link rate exceeds some pre-configured threshold and 
> the proportion of the marked packets is in proportion to the 
> excess traffic above this threshold

Georgios: We will try to make the description more clear in the 
next version of the draft.

Furthermore, please note that this draft specifies a Per Domain Behavior 
that provides the ability to Diffserv nodes located outside 
Diffserv domain(s), e.g., Diffserv enabled gateway, such as a IMS media
gateway
to detect when the resources provided by the Diffserv domain(s) are not
available. 
The unavailability of resources is indeed monitored and detected 
using the functionality mentioned by you:
"interior mark packets if the current link rate exceeds some pre-configured
threshold and 
the proportion of the marked packets is in proportion to the 
excess traffic above this threshold"

> * This amount of the marked packets may be scaled by a factor 
> N=10, e.g. 
> to make an excess rate of 5% more visible by marking 50% of 
> the packets.

Georgios: This is right!

> * Classify: I dont't know which virtual queue you are 
> referring to. In any case, packets should not be sent to a 
> different queue where they can expect longer delay to avoid 
> packet reordering.

Georgios: We are refering to the same physical queue, but using 
different virtual queues. You are right regarding the 
fact that marked and unmarked packets 
have to be scheduled in the same way.

> * If N>1 is used, marked packets should not be treated 
> differently, otherwise also in-profile traffic is violated.

Georgios: 
Note that marked and unmarked packets 
have to be scheduled in the same way, however the 
moment of dropping might be different.

> * Classify: I don't understand what you want to say by this paragraph.

Georgios: This is about Packet classification!
Sorry, we will clarify this point in the next version of the draft!

> 
> Typos:
> * of the receiving marked bytes -> received marked bytes
> * addres -> address
> * that the actually change -> actual change
> * one pre configured -> one pre-configured
> * a relative high level -> a relatively high level

Georgios: Thank you very much!

Best regards,
Georgios

> 
> Best wishes,
> 
>     Michael
> 
> --
> Dr. Michael Menth, Assistant Professor
> University of Wuerzburg, Institute of Computer Science Am 
> Hubland, D-97074 Wuerzburg, Germany, room B206
> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 
> mailto:[email-masked]
> http://www3.informatik.uni-wuerzburg.de/research/ngn
> 
>