Subject: [Tsvwg] Comments on RU PDB draft

From: mendes <[email-masked]>
Date: Mon, 02 Oct 2006 10:05:58 +0200

Dear all,

here are my major comments to the RU PDB draft.

  It is not clear the relationship of the proposed mechanism with a PDB,
since the proposed RU PDB is not based on a new  behaviour (domain wide
and node specific) to handle traffic. It seems more as a policy
mechanism which re-marks packet that are overloading existing PDBs.
Moreover, in DiffServ it is common to drop EF packets and re-mark AF
packets (to lower priority classes, such as BE) that overload the
defined profile for those classes. So, what is the impact of this idea
of re-marking non-compliant packets to a local_DSCP which has the same
PHB treatment as the original PDB in the DiffServ operational model?
  It is also not clear the motivation of this proposal in relation to
existing mechanisms that can detect congestion in the network and so,
allow the source of traffic to reduce rate of the admission control in
ingress point to be adjusted. Moreover, the application of this
congestion notification mechanisms seems to require less changes to the
DiffServ model than the proposed RU PDB.

Some parts of the draft require extra clarification, such as:
- If the original_DSCP is remarked to a local_DSCP, the latter one is
remarked to what?
- How do you implement the referred virtual queue?
- Since local_DSCP are re-marked pkts of the original_DSCP, why should
the former have less drop priority? Moreover, this since a mechanism
similar to the AF drop precedence.
-  it is said that this PDB can be applied in relationship to multiple
DiffServ domains. In is a strange sentence when referred to a
Per-Domain-Behaviour, which my definition is applied only to one domain.

Cheers
Paulo

19722fc8d3865b147c75ae2495625f2
X-Mailman-Approved-At: Mon, 02 Oct 2006 06:42:45 -0400
Subject: [Tsvwg] Comments on RU PDB draft
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Dear all,

here are my major comments to the RU PDB draft.

  It is not clear the relationship of the proposed mechanism with a PDB,
since the proposed RU PDB is not based on a new  behaviour (domain wide
and node specific) to handle traffic. It seems more as a policy
mechanism which re-marks packet that are overloading existing PDBs.
Moreover, in DiffServ it is common to drop EF packets and re-mark AF
packets (to lower priority classes, such as BE) that overload the
defined profile for those classes. So, what is the impact of this idea
of re-marking non-compliant packets to a local_DSCP which has the same
PHB treatment as the original PDB in the DiffServ operational model?
  It is also not clear the motivation of this proposal in relation to
existing mechanisms that can detect congestion in the network and so,
allow the source of traffic to reduce rate of the admission control in
ingress point to be adjusted. Moreover, the application of this
congestion notification mechanisms seems to require less changes to the
DiffServ model than the proposed RU PDB.

Some parts of the draft require extra clarification, such as:
- If the original_DSCP is remarked to a local_DSCP, the latter one is
remarked to what?
- How do you implement the referred virtual queue?
- Since local_DSCP are re-marked pkts of the original_DSCP, why should
the former have less drop priority? Moreover, this since a mechanism
similar to the AF drop precedence.
-  it is said that this PDB can be applied in relationship to multiple
DiffServ domains. In is a strange sentence when referred to a
Per-Domain-Behaviour, which my definition is applied only to one domain.

Cheers
Paulo