Subject: RE: [Diffserv] AF and PHB mutability requirements

From: "Weiss, Walter" <[email-masked]>
Date: Fri, 5 Nov 1999 14:03:35 -0500

Sergio,
 
The AF and EF PHBs allow specific behaviors. However, services are
constructed by configuring these behaviors (bandwidth, delay/queue depth,
drop thresholds, etc.). These variations in configuring the behaviors allow
for relatively unique services in any given DS domain. It is the intent of
the services that determines the ideal choices of PHB and configuration
values. This variation in the structure of services across domains leads to
potential mapping (re-marking) requirements. Both the EF and AF RFCs assume
that because these PHBs were choosen by the folks defining the service, it
makes the most sense to preserve the concepts of EF and AF across domains,
even if the packets require re-marking, shaping or dropping due to some SLS
restrictions.
 
If mappings of the service characteristics across domains are such that the
key elements of AF or EF are not the ones that best represent the service,
then there is nothing to prevent such a remarking. For example, if a
VLL-like service is provided using an AF PHB and the next domain only
supports VLL with EF, then it may be quite reasonable to remark from AF to
EF. However, the most compelling characteristic of AF is not its VLL
capability but its congestion management mechanism (drop precedence). If a
service was constructed to use drop precedence, it would be inappropriate to
map that to EF at a domain boundary. Although there nothing to preclude a
domain from remarking between EF and AF, it is not the optimal choice.
Hence, it is discouraged in both RFCs (explicitly in EF and implicitly in
AF).
 
regards,
 
-Walter

-----Original Message-----
From: CATANZARITI Sergio FTR&D/TI
[mailto:[email-masked]]
Sent: Friday, November 05, 1999 12:14 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [Diffserv] AF and PHB mutability requirements

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

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