Subject: RE: [Diffserv] Incompatibility between Diffserv and PPP based tun neling protocols

From: Shahram Davari <[email-masked]>
Date: Thu, 11 May 2000 13:35:09 -0700

Hi,

In the tunneling draft there are two types of tunnels:

1) Uniform
2) Pipe

In the Uniform case, the tunnel supports the same PHB as the tunneled flow.
In this case it seems logical to use multiple parallel tunnels to support
all tunneled PHBs. This is analogous to using multiple L-LSP tunnels.

In case of Pipe model, the tunnel may support a different PHB from the
tunneled flow. In this case, it may be possible to support all tunneled PHBs
with only one tunnel PHB. As Brian pointed out, an example is to choose EF
for the tunnel, then you could support almost all other PHBs.

-Shahram

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

---

From: [email-masked]
Date: Thu, 11 May 2000 18:49:42 -0400

Back to the original problem scenario:

> Let's assume that there are two micro-flows of traffic within a single
L2TP tunnel, marked for different PHBs.
> The DSCP mark has to be propagated from the original packet to the
tunneled header at tunnel ingress
> (as per section 2.5 of EF PHB). The restrictions on packet re-order apply
only to a packets belonging to
> a micro flow within a particular PHB class. So, it is possible for packets
belonging to different PHBs to get
> re-ordered by DS aware nodes en-route to tunnel egress. 
>
> This re-ordering breaks PPTP and L2TP.

This seems to be a classic "Doctor it hurts when I do *this*.
-- Don't do that." scenario.  The easiest solution is to mark
EF on all the outer headers.  Beyond that, upon reflection,
the "must" in Section 2.5 of the EF RFC appears to be overstated
- it probably ought to be a "should", perhaps accompanied
by language like that in Section 5 of the AF RFC.  There
are circumstances under which EF can be run through a
non-EF tunnel without damage (e.g., overprovisioned AF),
but it is necessary to understand what one is doing.
This leads to a solution with AF or a non-zero class
selector in the outer header of the tunneled packets.

> One way of solving this problem is to create multiple L2TP or PPTP
sessions and by
> dedicating one PHB for each session. Since both L2TP and PPTP allow
re-ordering
> across sessions, the packet re-order problem is not as nasty.

This looks like the right solution - in essence to run
multiple BAs among which reordering is desired through
a tunneling protocol that cannot tolerate reordering, one
needs to use multiple tunnels (e.g., one per BA).  For
the examples being discussed, this should "just work",
as each L2TP or PPTP session will appear to be a single
microflow to the diffserv-aware nodes and hence be governed
by the diffserv injunctions against reordering packets in a
microflow -- this seems like something that could be
productively clarified in the next version of the tunnels
draft, as it's not immediately obvious from the existing
documents.

A couple of other notes on points raised in the discussion:

> The suggestion to split the two microflows into 2 different tunnels will
work,
> however with thousands of tunnels to manage in an enterprise/carrier-class
VPN
> setup this will become an administrative nightmare.

If the tunnels are per-BA rather than per-microflow, the
resulting administrative consequences should be manageable.
If not, there's always the option of choosing not to make
diffserv forwarding distinctions within the tunnel -
there's an instance of the "no free lunch" principle here.

> What criteria should be used at the tunnel's ingress node to
> decide the traffic that can go through this tunnel? If the
> tunnel's DSCP is AF, can one send both EF and AF traffic
> through it? It may lead to degradation of service for the EF class.

While it may seem like hair-splitting, this is really a
traffic and network engineering problem.  Diffserv can
say that "degradation of service for the EF class"
is wrong, but leaves it to network and equipment
designers/implementers to figure out how to make sure
it doesn't happen.  Diffserv is not a substitute for
competent network/traffic design/engineering.  I think
Grenville's already made basically this point.

As Brian noted, this is a great opportunity to figure
out what else ought to be in the tunnels draft - as
the author of that draft, I'm open to any and all
suggestions that will help avoid future confusion.

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]  Cellular: +1 (978) 394-7754
---------------------------------------------------

---

From: Andy Koscinski <[email-masked]>
Date: Fri, 12 May 2000 16:43:10 -0700

-----Original Message-----
From: Rajesh Sundaram [mailto:[email-masked]]
Sent: Friday, May 12, 2000 2:35 PM
To: Brian E Carpenter; Grenville Armitage; David Black
Cc: [email-masked]; [email-masked]
Subject: RE: [Diffserv] Incompatibility between Diffserv and PPP based
tunneling protocols

So far, there are two proposed solutions to this problem. 

a) Mark the outer header packets of all tunneled packets with a uniform
codepoint. 

As Brian pointed out, this treats the tunnel like a virtual wire and works
well as long as there is sufficient bandwidth. But, there could be a problem
if EF bandwidth was limited. By multiplexing data and EF onto an EF tunnel,
we are increasing the probability of getting policed at a DS boundary, and
thereby breaking the guarantees of inner EF traffic.

  b) Create a (small)  

andyk> yes, but why small? should cover all required DSCP's.

> set of multiple tunnels,  

 each tunnel getting a fixed codepoint, that is distinct from other tunnels.
All packets on a particular tunnel carry the same uniform codepoint. Before
tunnel encapsulation, inspect the inner codepoint of the packet and route
the packet to the appropriate tunnel. 

andyk> I would replace the word "tunnel" by a "l2tp session" in the above
sentence. There is a "l2tp-DS-draft-extension" which suggests a negotiable
outer DSCP per session,

not per tunnel. Each microflow with an unique DSCP requirement maps into one
l2tp session with and individual outer DSCP, which migt be different from
the outer tunnel DSCP

and also might be different from the inner DSCP (or TOS) of the microflow at
tunnel ingress.

The packet sequence in every session (microflow) is preserved, if packet
sequencing is enabled. In addition the micro flow

might have a packet sequencing of it's own, on the higher layer protocol.

 I think the outer DSCP per l2tp session should be unidirectional,

and might be diferent for the l2tp payload flowing in two different
directions.

thx

andy 

 I had not necessarily suggested creating a different tunnel for each PHB
(or for each micro-flow). By creating a smaller set of tunnels, we are
reducing the management overhead. This approach would need a mapping of
inner DSCPs --> outer DSCPs, which is probably controlled by the local
tunnel administrator.

The first approach seems to be a special case of the second one (where there
all inner DSCPs map to a uniform outer DSCP). Also, the second one is more
flexible. I'd appreciate comments that help us make a decision on this. 

Thanks, 
Rajesh 

-----Original Message----- 
From: Brian E Carpenter [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, May 11, 2000 1:09 PM 
To: Grenville Armitage 
Cc: Rohit Chhapolia; [email-masked]; [email-masked]; David Black 
Subject: Re: [Diffserv] Incompatibility between Diffserv and PPP based 
tunneling protocols 

Three comments (on the whole thread): 

1. The correct place to write up the conclusion of this, when we 
reach one, is in draft-ietf-diffserv-tunnels-00.txt as revised. 

2. Remember that the diffserv rule that microflows must not 
be reordered is met by not reordering the whole BA, and is 
also met by not reordering the whole tunnel. It is completely 
conformant with diffserv to perform no reordering whatever. 
Viewed that way there is no problem, just an implementation 
constraint. 

3. We might need to add some words to RFC 2598 section 2.5, 
but I see no problem in enclosing an EF flow and other flows 
such as BE or AF within an EF tunnel, as long as the tunnel 
has adequate bandwidth and admission control. That's why we 
call it virtual wire. 

   Brian 

Grenville Armitage wrote: 
> Rohit Chhapolia wrote: 
>         [..] 
> In general the answer is more like 'it depends'. Since the 
> tunnel becomes more like a link, we need to understand its 
> ingress->egress QoS characteristics before we can decide 
> how well it would support any given mix of tunneled traffic. 
> Unfortunately knowledge of the tunnel's PHB alone doesn't 
> tell us all there is to know - it will depend on network 
> topology and router provisioning along the tunnel's path. 
> This is the nature of Diffserv (to date, although people are 
> working on defining e2e behaviors built from per hop behaviors) 
> 
> cheers, 
> gja 
> ________________________________________________________________________ 
> Grenville Armitage                    http://members.home.net/garmitage/
<http://members.home.net/garmitage/>  
> Bell Labs Research Silicon Valley 
> 
<http://www1.ietf.org/mailman/listinfo/diffserv>  
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
<http://www-nrg.ee.lbl.gov/diff-serv-arch/>  

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