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

From: Nabil Bitar <[email-masked]>
Date: Wed, 24 Nov 1999 12:12:10 -0500

Hi Nabil (Seddigh)
> 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?
> >
>
> 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.
>
This is clearly doable. However, how well does it scale (e.g. effected by a 
combination of static configuration and service scope) ?  Furthermore, it 
limits you to a static apriori knowledge. While there is use for such 
configuration, it is practically limiting from a  deployment scope and the 
type of services that you can practically offer. The question of whether 
you need to do the filtering at layer 3 or layer 4 depends on your traffic 
conditioning and what you to do offer.

> 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.
In my email, I was implicitly referring to "from one to anywhere" service.
>   receiver side ingress router would have to be dynamically
>   installed via  a tool (BB?) that is prompted based on
>   some trigger.
>
that is more like what I referred to in mechanisms needed to dynamically 
install filters. I am not sure if this in the realm of the BB now or 
whether it should be!

> 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.
>
The dynamic case is the more challenging and more generic.
> If as Brian's note indicates, the WG is thinking of standardizing
> services,
Mechanisms that enable the installation of dynamic filters in the way 
referred to above are service building blocks as much as PHBs are. Thus, 
such mechanisms do not imply specific services and do not require service 
standardization. In addition, I do not think that Brian is talking about 
standardizing services but rather probably working on services from 
informational perspective to see how the PHBs defined so far will be used 
and whether there is need for more.

> I suggest we clearly delineate and separate the discussion
> between provisioning of core router resources and co-ordinated
> configuration of edge devices rules.
>
What we are talking about is clearly an edge router issue. The above 
discussion is about how to instantiate traffic conditioning rules. I think 
such instantiation mechanisms are explicitly stated as part of the diffserv 
router conceptual model. Aren't they?

> Regards
> Nabil Seddigh
> [email-masked]
>

Regards,
Nabil Bitar. 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Nov 1999 15:05:17 -0600

People,

Diffserv (the topic of this WG) is clearly a stateless one-way hop-by-hop
mechanism. So this discussion - however important it is - is simply
out of scope for this mailing list. 

As has been said from the beginning, if you want symmetric behavior you need
symmetric service level specifications, and nothing in diffserv prevents this.
But it isn't this WG's job to worry about this.

   Brian Carpenter
   diffserv co-chair

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Attend INET 2000: http://www.isoc.org/inet2000
Non-IBM email: [email-masked]
Ethernet address: 00-00-AC-CF-5B-82

---

From: "Albert Manfredi" <[email-masked]>
Date: Sat, 27 Nov 1999 17:05:45 -0500

> out of scope for this mailing list.

Glad to see this reiterated by the co-Chair. I've seen some evidence
of cracks forming in this simple goal.

> But it isn't this WG's job to worry about this.

True, but people always want to know how this is possible given that
TCP is not going to mark its ACK packets with any special code
point.

Certainly one can envision that over "default" service, ACK packets
will get symmetric treatment, though. And this default service, over
the diffserv net, _could_ be something better than BE.

Bert
[email-masked]