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

"MORITA, Naotaka" <morita.naotaka@lab.ntt.co.jp> Tue, 11 November 2003 17:46 UTC

Received: from optimus.ietf.org ([]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12970 for <diffserv-interest-archive@odin.ietf.org>; Tue, 11 Nov 2003 12:46:19 -0500 (EST)
Received: from localhost.localdomain ([] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcaY-0005Li-0s for diffserv-interest-archive@odin.ietf.org; Tue, 11 Nov 2003 12:46:02 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABHk1x3020557 for diffserv-interest-archive@odin.ietf.org; Tue, 11 Nov 2003 12:46:01 -0500
Received: from localhost.localdomain ([] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcaX-0005LT-Ph; Tue, 11 Nov 2003 12:46:01 -0500
Received: from odin.ietf.org ([] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcaO-0005Kg-Em for diffserv-interest@optimus.ietf.org; Tue, 11 Nov 2003 12:45:52 -0500
Received: from ietf-mx (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12938; Tue, 11 Nov 2003 12:45:39 -0500 (EST)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 1AJcaM-00072Q-00; Tue, 11 Nov 2003 12:45:50 -0500
Received: from tama5.ecl.ntt.co.jp ([]) by ietf-mx with esmtp (Exim 4.12) id 1AJcaL-00072E-00; Tue, 11 Nov 2003 12:45:50 -0500
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp []) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hABHjlUC028501; Wed, 12 Nov 2003 02:45:47 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (localhost []) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hABHjlpo001464; Wed, 12 Nov 2003 02:45:47 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp []) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hABHjl8H019773; Wed, 12 Nov 2003 02:45:47 +0900 (JST)
Received: from imj.m.ecl.ntt.co.jp (localhost []) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id CAA06351; Wed, 12 Nov 2003 02:45:46 +0900 (JST)
Received: from morita-ibmthink.lab.ntt.co.jp by imj.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id CAA08127; Wed, 12 Nov 2003 02:45:44 +0900 (JST)
Message-Id: <>
X-Sender: nm014@imj.m.ecl.ntt.co.jp (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr5
Date: Mon, 10 Nov 2003 23:18:37 -0600
To: Roland Bless <bless@tm.uka.de>
From: "MORITA, Naotaka" <morita.naotaka@lab.ntt.co.jp>
Cc: diffserv-interest@ietf.org, "'tsvwg@ietf.org'" <tsvwg@ietf.org>
In-Reply-To: <20031111052827.348154fd.bless@tm.uka.de>
References: <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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


At 05:28 03/11/11 +0100, Roland Bless wrote:
 >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
 >   control.

That is right.  I will check the meaning of PDP.

 >> 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.

But the important factor is the bandwidth limitation is shared between two 
Sequence integrity is another one.
How do I describe such things by isolated PHBs?
Anyway, what is CSC?

 >>  >- 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.

I see.  Again, I will check PDB.

 >>  >- 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.

I will soon show you the difference between srTCM and my proposed two-threshold.

 >>  >- 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
 >> 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.

Thank you.  I will do that.
For the correctness of the feedback information is a target of media 
monitor server.

 >Best regards,
 > Roland
 >tsvwg mailing list

Diffserv-interest mailing list