Re: AW: [Diffserv] about the concern of a rate loss in the definition ofdraft-charny-ef-definition-00

[Brian E Carpenter <[e-mail]>]

Jon,

I didn't think I was saying anything contentious.

Jon Bennett wrote:
> 
> > It's not just the spirit, it is the formal definition of a PHB. A PHB
> > specification describes the behavior of a node for a BA, i.e.
> > the outbound stream of packets carrying  the corresponding DSCP,
> > regardless of their origin, of merging within the node, or of
> > their attribution to different microflows.
> >
> > Which tells you that any assertions about rate, latency, or jitter
> > should refer to the BA, not to the individual flows within the BA.
> 
> I find this to be a strange comment given that;
> 
> a) The discussion on this thread has been almost totally about BA rate,
>   jitter, etc and not about individual flow jitter.

Mostly yes, but a few times it seemed to me people were not clearly
separating the concepts. If that's not the case so much the better.

> 
> b) The VW draft spends almost all of its time discussing per flow
>    jitter and you didn't raise this complaint when that draft was
>    presented.

I want to consider this comment carefully, not so much w.r.t. VW but
for the general PDB definition. I was referring very specifically
to PHBs of course.

> 
> c) We have to discuss what assertions can be made about the
>    behavior of individual flows in the aggregate because we can
>    only build on the PHB if we can say something about what
>    will happen to the microflows in the aggregate.

Yes, when describing PDBs that is certainly a valid point. But it's
explicitly excluded from PHB definitions by RFC 2474/5, specifically
to avoid a *requirement* for per microflow state (but see below).

> 
> > I'm glad you brought this up, because I was wondering last
> > night whether
> > people had lost sight of it.
> >
> >   Brian
> >
> > P.S. this doesn't stop vendors trying to do better, but it does
> > limit what goes in PHB definitions.
> 
> It is probably worth pointing out that an implication of this last
> comment, which is also more explicitly stated in
> draft-ietf-diffserv-model-04 is that the statement that microflow
> awareness can not be a *requrirement* of a PHB is very different
> from saying it is ok if the PHB definition in effect *prohibits*
> microflow awareness.

Absolutely. That's been agreed since the interim meeting in Cambridge.

> 
> I have heard a number of comments of the form "why don't we just
> make the definition 'a packet can be delayed by no more than X?'"
> such a definition would in effect prohibit a router from being
> microflow aware.
> 
> The reason that a definition with a single fixed
> latency/jitter/etc term for each *packet* would prohibit microflow
> awareness can be seen in this example. Suppose the EF aggregate
> traffic contained some high rate VW traffic and some much lower
> rate VoIP traffic, a good way to serve this traffic would be to
> give higher precedence/weight to the VW traffic than to the VoIP
> traffic.
> 
> This would give the VW traffic a lower jitter/latency which it
> would want and the VoIP traffic a higher jitter/latency which
> with a much looser jitter bound it could easily handle. If a
> fixed jitter/latency requirement were imposed which could support
> the VW requirements then this approach would not work or would
> only work at a lower traffic load.
> 
> The VW PDB draft mentions ways of dealing with microflows in
> the aggregate with different rates, and that one solution would
> be to have different DSCP's for different rates. This statement
> assumes FIFO service of the aggregate traffic. If a router was
> microflow aware it could service packets belonging to different
> rate microflows.... differently. And thus address this issue
> without the need to consume multiple DSCP's, the need to
> coordinate the rate mappings between ISPs or between ISPs
> and their customers, etc..

My opinion is that this is a domain we should leave to
vendors and the marketplace, at least in our present state
of knowledge.

> 
> jon
> 
> _______________________________________________
> diffserv mailing list
> [e-mail]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org
Non-IBM email: [e-mail]

_______________________________________________
diffserv mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/