Subject: RE: [Diffserv] Diff-Serv Router Policies on ACK packets

From: Nabil Bitar <[email-masked]>
Date: Tue, 23 Nov 1999 09:54:32 -0500

On Tuesday, November 23, 1999 12:33 AM, Kathleen Nichols 
[SMTP:[email-masked]] wrote:
>
>
>> Although the WG will discuss characteristics of behavior aggregates
> that are formed subject to certain rules enforced by edge behaviors
> and handled by certain configurations of particular PHBs, it
> seems more a topic of research whether ACKs *should* be of the
> same behavior aggregate. It would seem best to attempt to use
> the same behavior aggregate for ACKs as for the DATA they are
> ACK'ing in the absence of clear indicators to the contrary, but
> this doesn't seem to me like a topic for standardization.
>
>         Kathie
>

Hi Kathie,

I don't see whether currently there is a capability to mark the ack packets 
with the same BA as the data at the ingress router for the acks. This goes 
back to the fact that diffserv is focused now on unidirectional traffic 
where marking and policing is sender based. That is, DATA sent will be 
marked and policed according to the sender's profile. The same for the 
ACKs, they will be marked and policed according to the ack sender's 
profile. There are variations on this where a mutli-field classifier at the 
ingress router that includes destination ip address and destination port 
number will make it easier, although this requires apriori knowledge of 
this information. the generic problem where dynamic coordination is made 
between the two ends of a tcp sessions based on either end's BA is not 
addressed yet.  Additionally, this problem is beyond acks. I see it 
effecting any two-way sessions by which the session quality is effected by 
both directions of the traffic. An example that I stated some time back is 
a VoIP service when one end of the session has golden service (built using 
EF or some AF class) and the other has best-effort service. Can one make 
both directions have golden services in that case for the duration of the 
session? If not, the person with the golden service will get the quality of 
that service when he/she talks to another person with the same service 
level or better. Are mechanisms that allow this sort of things still out of 
the scope of the WG?

Nabil.

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

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

---

From: "Nabil Seddigh" <[email-masked]>
Date: Tue, 23 Nov 1999 12:32:53 -0500 (EST)

Nabil Bitar wrote:

>I don't see whether currently there is a capability to mark the 
> ack packets with the same BA as the data at the ingress 
> router for the acks. This goes back to the fact that diffserv
> is focused now on unidirectional traffic...
>
> [..............stuff deleted.....]
>
> Additionally, this problem is beyond acks. I see it 
>effecting any two-way sessions by which the session quality 
> is effected by both directions of the traffic. An example that 
> I stated some time back is a VoIP service when one end of 
> the session has golden service (built using EF or some AF 
> class) and the other has best-effort service. Can one make
>both directions have golden services in that case for the 
>duration of the session? If not, the person with the golden 
> service will get the quality of that service when he/she talks 
> to another person with the same service level or better. 
> Are mechanisms that allow this sort of things still out
>of the scope of the WG?Nabil.Plan
>

Hi Nabil :)

I agree with your statement that the problem is beyond ACKs
and also extends to VoIP services etc. In general, in SOME 
cases, there are requirements for utilities and schemes to install
"correlated" filters/classifiers at ingress routers of both
communicating parties. To some extent, this is already possible
today.

Today, it is actually possible to have pre-installed (relatively static)
filters that allow:

  - One-to-one services (source & destination are fixed)
  - One-to-few services ( source and few destinations are fixed)

With the above, one can clearly construct a number of services
where both ingress routers have the same rules for the two
communicating parties. This can be done using standard policy 
management tools. Neither of the above two types of services
would NECESSARILY require Layer 4 information. Filters can 
be based on Layer 3 information alone.

There are 2 other cases for which additional mechanisms
are required to enable installation of "duplicate" filters
at 2 ingress routers.

a.) In the case where a one-to-anywhere service is offered
  (as in today's Internet), and there is a need to have
  "duplicate" filters, the filter on the sender side can
  be static and pre-installed. However, the filter on the
  receiver side ingress router would have to be dynamically
  installed via  a tool (BB?) that is prompted based on 
  some trigger. 

b.) The case where both filters are dynamically installed 
     via a tool that is prompted based on a trigger.

BTW, the above discussion  acknowledges the need for both static and
dynamic setting of filters. This is independent of the approach to
provisioning.  It is possible to have static/dynamic filters in
combination with static  provisioning. 

If as Brian's note indicates, the WG is thinking of standardizing
services, I suggest we clearly delineate and separate the discussion
between provisioning of core router resources and co-ordinated
configuration of edge devices rules.

Regards
Nabil Seddigh
[email-masked]