Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted

From: Juha Heinanen <[email-masked]>
Date: Wed, 10 Nov 1999 22:36:25 +0200 (EET)

Jamel H. Sadok writes:

 > I have a problem  getting to  terms with the idea  that an existing
 > domain would need to establish some AF SLAs  in order to forward
 > its existing BE traffic. Is this  a  conensus or  am  I missing the
 > point? IMHO, I would rather think that todays
 > traffic would be tomorrow's default  and let  AF handle the new higher
 > priority stuff. That  way if my  domain is A-DiffServ it may go on for a
 > while (life as normal). 

there doesn't need to be any concensus on how diff-serv phbs are used to
implement services.  to me best effort SERVICE is a special case of
assured bandwidth SERVICE where the assured bandwidth is zero.  if i
implement assured bandwidth service using af class 1, then i would
simply tell to my routers that the precedence code point 000 is an alias
of af 1, dp level yellow code point.

-- juha

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

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 10 Nov 1999 22:32:05 +0200 (EET)

Grenville Armitage writes:

 > new mythical 'background traffic'

i don't see any mythical in definition of background SERVICE.  it is a
service to which no promises nor even expectations are made.  it can be
IMPLEMENTED as an af class that has been allocated some buffering
resources, but no scheduling resources, i.e., packets from the
background queue would be served only is all other queues are empty.  it
would thus be possible for the other traffic to totally starve the
background traffic.  provided that background traffic is cheaper than
best effor ttraffic, it would have uses.  one could, for example, try to
download some content during the nigth and consume it in the morning
provided that it has arrived.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 10 Nov 1999 22:22:17 +0200 (EET)

Jamel H. Sadok writes:

 > It may  be that many users won't be able to *afford*  the price of
 > remarking their existing legacy traffic  to a suitable AF class and yet
 > would still like to see their "ïmportant traffic" differenciated from
 > backgound traffic.

i'm not sure it i understand you, but if a user wants to send some of
its packets as background, then it must mark those with a code point
that is different from best effort.

-- juha

---

From: "Albert Manfredi" <[email-masked]>
Date: Wed, 10 Nov 1999 16:53:11 -0500

Juha Heinanen wrote:

> background queue would be served only is all other queues
> are empty.

Which is a good description of standard BE traffic handling.

I think the real issue here is that some feel that TOS 00000000
should _not_ map into DSCP 000000, but rather into some "slightly
higher" DSCP. If that's the case, then at the interface between the
edge and the DiffServ, that translation can always be accomplished,
no? It's of course an exercise for the student to know just what
incoming TOS is mapped to this new DSCP BE, vs what incoming TOS
becomes the bottom-feeder DSCP.

Perhaps this can be filtered based on Source IP Address.

> it

And again, this can be accomplished by somehow mapping TOS 0 to some
slightly better than 0 DSCP. Assuming you can still differentiate
the incoming packets.

Bert
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Nov 1999 06:07:01 -0600

Albert Manfredi wrote:
...
> should _not_ map into DSCP 000000, but rather into some "slightly
........................^PHB
> higher" DSCP. 
..........^PHB

   Brian

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 17 Nov 1999 02:01:22 +0200 (EET)

Albert Manfredi writes:

 > > it can be

not quite, since traditionally be has had some forwarding resources
allocated to it.

-- juha