Subject: [Diffserv] AF and PHB mutability requirements

From: CATANZARITI Sergio FTR&D/TI <[email-masked]>
Date: Thu, 4 Nov 1999 21:13:49 -0800

In the AF PHB Group spec, there is no specific PHB mutability section. But
the possibility is given under Traffic Conditioning Actions:
> A DS domain MAY at the edge of a domain control the amount of AF traffic
that enters or exits the domain at various levels of drop precedence. Such
traffic conditioning actions MAY include traffic shaping, discarding of
packets, increasing or decreasing the drop precedence of packets, and
reassigning of packets to other AF classes. However, the traffic
conditioning actions MUST NOT cause reordering of packets of the same
microflow.>
So, is it possible to reassign packets ONLY to different AF classes as
action of traffic conditioning?
What about other SLS-based boundary service semantics changing reasons? The
latter case seems in sync with the principles of the architecture of the
diff serv model where PHB/DSCP mapping looks like more a service definition
and implementation issue, although EF prohibits that:
>Mutability Packets marked for EF PHB MAY be remarked at a DS domain
boundary only to other codepoints that satisfy the EF PHB. Packets marked
for EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS domain>
Please, could somebody from the AF document authors team clarify that and
put it in a PHB mutability section?

The problem is that looking at both the DS framework and the architecture
document, this PHB/DSCP re-marking/changing issue looks really confusing (at
least to me): 

From the architecture document:

>2.3.3.2 Markers Packet markers set the DS field of a packet to a particular
codepoint, adding the marked packet to a particular DS behavior aggregate.
The marker may be configured to mark all packets which are steered to it to
a single codepoint, or may be configured to mark a packet to one of a set of
codepoints used to select a PHB in a PHB group, according to the state of a
meter. When the marker changes the codepoint in a packet it is said to have
"re-marked" the packet.>

From the framework document:

>Markers police by re-marking the traffic with a different codepoint either
- to demote out-of-profile traffic to a different PHB, - as a result of an
SLS which specifies codepoint mutation, or - to ensure that only valid
codepoints are used within the domain.>
So, is it possible to change DSCP as long it is PHB service semantic
compatible? Is it possible to change DSCP as long it is SLS-compatible? Is
it possible to change DSCP as long it is PHB-group compatible? All of the
above, none of the above, open issue, out of scope issues, etc..
Please, an explanation short and as simple as possible considering that I
have attended only the elementary school (but a public one, luckily enough),
not a discussions flame.
Thanks,
Sergio
> --------------------------------------------------------------------
> Sergio Catanzariti
> Senior Project Manager, Technology Integration
> France Telecom R&D 
> 1000 Marina Boulevard Suite 300 
> Brisbane CA 94005
> Tel. 650-875-1526
> Fax. 650-875-1505
> email:[email-masked] 
> --------------------------------------------------------------------
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Nov 1999 10:40:16 -0600

Sergio,

The diffserv architecture doesn't place any limits on re-marking,
as long as the re-marking conforms with the traffic conditioning
specification in place.

It is quite acceptable for individual PHB specifications to
place limits on re-marking (for example the re-ordering constraint
mentioned in AF).

There is nothing that I can see that stops a TCS specifying
that AF traffic should be re-marked as EF to cross a VLL, but then it
might need to go through an MF classifier at the other end to restore
the AF marking.

  Brian

> CATANZARITI Sergio FTR&D/TI wrote:
> 
> In the AF PHB Group spec, there is no specific PHB mutability section.
> But the possibility is given under Traffic Conditioning Actions:
> 
> > A DS domain MAY at the edge of a domain control the amount of AF
> traffic that enters or exits the domain at various levels of drop
> precedence. Such traffic conditioning actions MAY include traffic
> shaping, discarding of packets, increasing or decreasing the drop
> precedence of packets, and reassigning of packets to other AF classes.
> However, the traffic conditioning actions MUST NOT cause reordering of
> packets of the same microflow.>
> 
> What about other SLS-based boundary service semantics changing
> reasons? The latter case seems in sync with the principles of the
> architecture of the diff serv model where PHB/DSCP mapping looks like
> more a service definition and implementation issue, although EF
> prohibits that:
> 
> boundary only to other codepoints that satisfy the EF PHB. Packets
> marked for EF PHBs SHOULD NOT be demoted or promoted to another PHB by
> a DS domain>
> 
> Please, could somebody from the AF document authors team clarify that
> and put it in a PHB mutability section?
> 
> The problem is that looking at both the DS framework and the
> architecture document, this PHB/DSCP re-marking/changing issue looks
> really confusing (at least to me):
> 
> >2.3.3.2 Markers Packet markers set the DS field of a packet to a
> particular codepoint, adding the marked packet to a particular DS
> behavior aggregate. The marker may be configured to mark all packets
> which are steered to it to a single codepoint, or may be configured to
> mark a packet to one of a set of codepoints used to select a PHB in a
> PHB group, according to the state of a meter. When the marker changes
> the codepoint in a packet it is said to have "re-marked" the packet.>
> 
> >Markers police by re-marking the traffic with a different codepoint
> either - to demote out-of-profile traffic to a different PHB, - as a
> result of an SLS which specifies codepoint mutation, or - to ensure
> that only valid codepoints are used within the domain.>
> 
> compatible? Is it possible to change DSCP as long it is
> SLS-compatible? Is it possible to change DSCP as long it is PHB-group
> compatible? All of the above, none of the above, open issue, out of
> scope issues, etc..
> 
> Please, an explanation short and as simple as possible considering
> that I have attended only the elementary school (but a public one,
> luckily enough), not a discussions flame.
> 
> Thanks,
> Sergio
> 

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