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

["MORITA, Naotaka" <[e-mail]>]

Roland,

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

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
 >[e-mail]
 >https://www1.ietf.org/mailman/listinfo/tsvwg 



_______________________________________________
Diffserv-interest mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/diffserv-interest