Subject: [Diffserv] Diffserv and Tunnels issues for discussion

From: [email-masked]
Date: Fri, 3 Dec 1999 19:11:03 -0500

At the end of the DC meeting I promised to post the questions
on the last slide of the Diffserv and Tunnels presentation
for further discussion.  The current draft is
draft-black-diffserv-tunnels-00.txt, and the intent
is to use the comments from this discussion to revise
that to a working group draft and submit that within
the next few weeks.  So, here are the questions
that were on the final slide plus some explanations: 

	Is keeping DSCP only in IP headers ok?

This is about whether to specify things like a
tunnel ingress traffic conditioner that spits
out two DSCPs (inner and outer headers) or a tunnel
egress traffic conditioner that takes two DSCPs as
part of its input. Such conditioners would complicate
the diffserv conceptual model, and are difficult to
impossible to implement for some tunnels (e.g., L2TP).

	Set to zero or class selector as simple TC?

This concerns situations in which full traffic conditioning
support is undesirable for some reason (e.g., need to muck
with the inner IP header's DSCP after encapsulation).  What
should we recommend to tunnel implementers as something simple
to deploy if they can't or don't want to put in full diffserv
traffic conditioning?  The draft suggests the ability to
zero the DSCP or set it to one of the class selector DSCP
values.  Another alternative would be to set to any DSCP
value (fixed by configuration).

	Egress selection approach ok?

This refers to the rationale in the draft that tries to make
the case that although there are always two DSCPs at a tunnel
egress, it is usually the case that only one of them contains
interesting information.  Hence the draft describes configurable
support for selecting one or the other DSCP.  Is this rationale
and approach reasonable?

	Egress selection operators - right ones?

The draft describes four selection operators.  Of particular
interest here is whether the convention of using the DSCP value
000000 as a possible "escape" (meaning "see the other DSCP")
is a reasonable and useful approach.

	What to recommend?

The draft is currently more of a survey than anything else.
It needs a short section of crisp recommendations for the future
tunnel RFC author whose AD tells him/her that diffserv has
to be considered in the design.  What SHOULD that author do?

	Any other comments?  IPsec? Translators?

I've received a few interesting offline comments.  Tunnels
span a surprisingly broad spectrum, and I've had two different
people tell me that for the sort of tunnels they think about,
only one of the two conceptual tunnel models (uniform and pipe)
makes sense -- but it was a different model in each case :-).
Hence, I think both models stay, but if there are better terms
for them that are already used in other contexts (e.g., I
think I've heard the "pipe" model referred to as a "virtual
wire"), I'm open to suggestions.

In addition, some people have pointed out that MPLS and layer
2 headers have some resemblance to outer headers in tunnels,
and hence also should be discussed.  One important difference
here is that in contrast to the general IP in IP tunnel case,
it's much more reasonable to build traffic classifiers that
look at both the outer (MPLS or layer 2) and inner (IP) headers.

Finally, Geoff Huston promised me a strong opinion on the
subject of why and how the rationale in the draft is horribly
confused, even though the low level mechanisms discussed
are a more or less reasonable approach.

Ok, comments, please ... otherwise you run the risk of
me substituting my opinion for that of the WG ;-).

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
[email-masked]
---------------------------------------------------

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

---

From: Jyrki Soini <[email-masked]>
Date: Wed, 8 Dec 1999 16:33:03 +0200 (EET)

> that were on the final slide plus some explanations: 

I prefer making things simple. The model I have in mind is like:

IN -> tunnel ingress -+-> inner header -+-> tunnel egress +-> OUT 
                      +-> outer header -+                 |    ^
                                                          +-> (conditioner)

IN: traffic is already conditioned
tunnel ingress: there is a policy for the tunnel that has two choises:
	- copy DSCP from IN in traffic to outer header
	- set outer header DSCP to a fixed value for the tunnel
inner header: unchanged IN packet header
outer header: initially set at tunnel ingress, but may change on the way to
	tunnel egress.
tunnel egress: there is a per tunnel policy performed to all packets that
	has three choises for OUT packet DSCP:
	- use inner header DSCP
	- set OUT packet DSCP the same as outer header has
	- set OUT packet DSCP to a fixed value
(conditioner): optionally feed all traffic from the tunnel to a conditioner
	that would make translation to DSCPs that are used in local diffserv
	domain

> impossible to implement for some tunnels (e.g., L2TP).

I find adding tunnel egress traffic conditioner unnecessary. 

> value (fixed by configuration).

Usually use original packet DSCP codepoint.

One situation that might make you to set a specific value is e.g.
tunnelling between diffserv capable operators that use the same
codepoint value for different services via a transfer operator
mapping the services inbetween.

Another might be seriously security concerned ipsec tunnel. Setting
the codepoint of tunnel would make it impossible to distinguish packets
from packets from packets.

> support for selecting one or the other DSCP.  Is this rationale

Usually it is.

> is a reasonable and useful approach.

I find it confusing and even not working. Traditionally 000000 is used
to mark best effort traffic.  Consider sending best effort traffic in
a tunnel. In the middle there is a transit operator that changes outer
header codepoint to AF1. Tunnel end-point would then unintentionally
classify originally best effort traffic to AF1.

> 	Any other comments?  IPsec? Translators?

I think the selection operators are not needed. Keep it simple.
Usually the tunnel end-points need to be configured before the
use. Even in case of dynamic tunnels it is necessary to make some
policy configurations which tunnels to accept. It should be straight
forward to extend the policies to include information how to handle
DSCP values.
 
> look at both the outer (MPLS or layer 2) and inner (IP) headers.

Wouldn't it just be simpler to use only IP header? After all, the
higher you are on the protocol stack the more you know about what
class of service is needed. Using lower layer information tend to
disturb the decission making.

> me substituting my opinion for that of the WG ;-).

  Jyrki Soini                |  [email-masked]
  Manager, Network Planning  |  tel. +358 2040 64725
  Sonera Solutions Ltd       |  fax. +358 2040 64652
  ---------------------------+------------------------
  P.O.Box 743                |  Kumpulantie 3
  FIN-00051 SONERA           |  Helsinki
  FINLAND                    |  FINLAND