[Diffserv-interest] Re: [Tsvwg] Re: [NSIS] PPS and MF-PHB

Roland Bless <bless@tm.uka.de> Tue, 11 November 2003 04:29 UTC

Received: from optimus.ietf.org ([]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04801 for <diffserv-interest-archive@odin.ietf.org>; Mon, 10 Nov 2003 23:29:19 -0500 (EST)
Received: from localhost.localdomain ([] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJQ9G-0007WK-Gq for diffserv-interest-archive@odin.ietf.org; Mon, 10 Nov 2003 23:29:02 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB4T2nf028907 for diffserv-interest-archive@odin.ietf.org; Mon, 10 Nov 2003 23:29:02 -0500
Received: from localhost.localdomain ([] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJQ9F-0007Vc-CE; Mon, 10 Nov 2003 23:29:01 -0500
Received: from odin.ietf.org ([] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJQ8W-0007Ua-16 for diffserv-interest@optimus.ietf.org; Mon, 10 Nov 2003 23:28:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04761; Mon, 10 Nov 2003 23:28:02 -0500 (EST)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 1AJQ8T-0004V9-00; Mon, 10 Nov 2003 23:28:13 -0500
Received: from iramx2.ira.uni-karlsruhe.de ([]) by ietf-mx with esmtp (Exim 4.12) id 1AJQ8T-0004V6-00; Mon, 10 Nov 2003 23:28:13 -0500
Received: from irams1.ira.uni-karlsruhe.de ([] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1AJQ8P-0006FO-00; Tue, 11 Nov 2003 05:28:09 +0100
Received: from i72ms1.tm.uni-karlsruhe.de ([] helo=smtp.ipv6.tm.uni-karlsruhe.de ident=8) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 1AJQ8P-0000B6-00; Tue, 11 Nov 2003 05:28:09 +0100
Received: from localhost ([::1] helo=i72mn12.tm.uka.de ident=3010) by smtp.ipv6.tm.uni-karlsruhe.de with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.12) id 1AJQ8N-0007vB-00; Tue, 11 Nov 2003 05:28:07 +0100
Date: Tue, 11 Nov 2003 05:28:27 +0100
From: Roland Bless <bless@tm.uka.de>
To: "MORITA, Naotaka" <morita.naotaka@lab.ntt.co.jp>
Cc: diffserv-interest@ietf.org, "'tsvwg@ietf.org'" <tsvwg@ietf.org>
Message-Id: <20031111052827.348154fd.bless@tm.uka.de>
In-Reply-To: <>
References: <> <> <>
Organization: Institute of Telematics, University of Karlsruhe
X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv-interest] Re: [Tsvwg] Re: [NSIS] PPS and MF-PHB
Sender: diffserv-interest-admin@ietf.org
Errors-To: diffserv-interest-admin@ietf.org
X-BeenThere: diffserv-interest@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/diffserv-interest>, <mailto:diffserv-interest-request@ietf.org?subject=unsubscribe>
List-Id: Differentiated services general discussion <diffserv-interest.ietf.org>
List-Post: <mailto:diffserv-interest@ietf.org>
List-Help: <mailto:diffserv-interest-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/diffserv-interest>, <mailto:diffserv-interest-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi Naotaka,

>  >After reading draft-morita-tsvwg-mfphb-00.txt and attending your
>  >presentation, I have some remarks related to this approach:
>  >- I'm not quite sure whether this is really a PHB definition.
>  >  It seems to me, that it is actually a mix of
>  >  * a scheme for measured-based admission control and resource provisioning
                     ^^^^^^^^sorry, should have been: measurement-based admission control
>  >  * a Per-Domain Behavior (see RFC 3086)
>  >  * a PHB group description

> Your understanding is correct, but I do not think it is a mix.
> The key of the PPS is to utilize PHB for admission control.

Hmm, I disagree here. A PHB usually describes an
"externally observable forwarding treatment", basically how
a node treats a packet during the forwarding procedure
(typically boils down to queue management and scheduling issues).
In your case, that both PHBs (MF-H,MF-M) get their own assigned 
resources (bw limitation) and that MF-M has a higher drop precedence
than MF-H. On top of that PHB group you define an admission
control procedure with additional traffic conditioning mechanisms
(your token bucket descriptions). This fits better to a PDB 
description in my opinion. And as you state in section 5:

   The Priority Promotion Scheme can be viewed as a kind of admission

> The proposed new PHB, MF-PHB refers to two-subclasses,
> but we do not have to define it as a group description.

What you call "sub-classes" are effectively two different PHBs: you will
need two distinct DSCPs and each DSCP will be mapped to a distinct PHB
that will cause a specific packet forwarding treatment. RFC 2475 defines
a PHB group as "a set of one or more PHBs that can only be meaningfully
specified and implemented simultaneously,....". Please, see also RFC 3260
for clarification on the AF class as a PHB group. MF-H makes not much
sense without MF-M and vice versa. However, I think your PPS admission control 
scheme can be applied to an AF class as well as to the CSC PHBs, therefore you 
don't need two new PHBs.

>  >- The scheme inherently relies on feedback information and it should be made
>  >  clear how the feedback can be provided (you mentioned RTCP as an example,
>  >  what about others?).
> Yes, it is.  As the PPS, I would like to describe the feedback mechanims,
> but for a PHB, we do not have to.

Yes, for a PHB you don't have to, but that's exactly why admission control 
should be defined not together with the PHB. EF also requires some form of
admission control to achieve the timely forwarding, but admission control 
procedures are not defined within RFC 3246. Your admission control procedure
will not work without feedback, but the PHBs will. Therefore, define a PDB
that defines constraints for corresponding PHBs.

>  >- Instead of defining a new PHB, possibly two Class Selector PHBs
>  >  or even an AF class can be used ("green" packets get high priority after
>  >  admission control, "yellow" and "red" packet may be used for probing).
>  >  AF usually gives no guarantees for delay and jitter, however, if AF is
>  >  provisioned properly, "green" packets may get some guarantee.
> This kind of disucssion is what I wanted to do.
> Sorry for spending much time on me presentation only.
> Are you refering to Three Color Marker in RFC2697 and RFC2698?

Not exactly, because I was not referring to packet marking, 
but as in those RFCs, I used the color code as an equivalent
for the drop precedence (i.e., "green"=AFx1, "yellow"=AFx2, "red"=AFx3).
Note that, the AF class definition allows also to implement only two (instead of 
three) effective different levels of loss probability for an AF class x.

>  >- For security and robustness, it is essential to police the markings
>  >  for the higher priority. Otherwise the service guarantees for other users
>  >  are violated by a malicious or ill-behaving end-system. Therefore, I think
>  >  first-hop routers should do the policing (based on the feedback
>  >  information?).
> I agree.  Are there any opinion about the description in pps framework document?
> Not sufficient?

Yes, I think some issues in 4.4 need more discussion. E.g., how do you ensure
that the feedback information is correct (you only state that "The behavior
in the direction from the destination to the source should also be correct")?
Some aspects should possibly be moved to the security section.

Best regards,

Diffserv-interest mailing list