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

From: Mahalingam Mani <[email-masked]>
Date: Wed, 10 May 2000 19:07:21 -0700

What if the desired PHB is as required on a per-microflow basis - even over
the
tunnel? Especially the case with IKE tunnels where one may encounter
multiple
DS router hops in the tunnel?

This is an issue with IPSec (IKE tunnels) - on similar lines. More so
because
if reordering is more than a certain (RFC-)suggested (which is a window of
32
packets - or more, as implemented) number then it is flagged as a replay
attack.

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.

-mani
> -----Original Message-----
> From: Grenville Armitage [mailto:[email-masked]]
> Sent: Wednesday, May 10, 2000 6:05 PM
> To: Rajesh Sundaram
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Diffserv] Incompatibility between Diffserv and PPP based
> tunneling protocols
> 
> 
> 
> It isn't always the case that the outer DSCP (carried in the tunneling
> IP header) has to be copied from the DSCP of the IP packet being
> tunneled. In this case, when reordering of the tunnel's contents is
> a bad thing, the tunneling header ought to be given some relatively
> fixed DSCP (one that ensures 'appropriate' QoS across the tunnel's
> length). This would ensure that the aggregate of all traffic
> going through the tunnel is treated as a single non-reorderable 'flow'
> by the DS routers along the tunnel's path.
> 
> cheers,
> gja
> 
> > Rajesh Sundaram wrote:
> > 
> > Folks,
> > 
> > There seems to be an incompatibility between tunneling 
> protocols that
> > encapsulate PPP (like L2TP and PPTP) and Diffserv PHBs.
> > 
> > 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. PPTP is required to 
> discard re-ordered
> > packets in order to maintain the ordering semantics of PPP. 
> L2TP allows for
> > the receiver to restore the original sequence of re-ordered 
> packets, but doing
> > this negates the benefits of the PHB, since the packet will 
> potentially remain
> > in the receiver's tunnel buffer for a long time.
> > 
> > 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.
> > 
> > Any suggestions on how this incompatibility can be addressed ?
> > 
> > Thanks,
> > Rajesh.
> 
> -- 
> ______________________________________________________________
> __________
> Grenville Armitage                    
> http://members.home.net/garmitage/
> Bell Labs Research Silicon Valley
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 

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

---

From: Grenville Armitage <[email-masked]>
Date: Thu, 11 May 2000 01:12:30 -0700

> DS router hops in the tunnel?

I'm not really sure how to parse your question. In general
tunnels provide isolation - conventionally just topological
isolation, but increasingly we're having to consider temporal
isolation (aka QoS). So consider the tunnel as becoming more
like a link substitute in that one provisions the tunnel's
temporal characteristics (QoS) to, in the aggregate, support
the mix of traffic flowing through it. In the same way that
we might mix EF and AF traffic on a single T1 line, so we
might mix all sorts of traffic onto a tunnel having a fixed
DSCP of its own. The tunnel's QoS is determined by the outer
DSCP (and the provisioning of the DS routers along the path
followed by the tunnel).

cheers,
gja

---

From: Rohit Chhapolia <[email-masked]>
Date: Thu, 11 May 2000 09:04:05 -0400

> DSCP (and the provisioning of the DS routers along the path

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.

Rohit

-- 
Rohit Chhapolia
Globespan, Inc.
mailto:[email-masked]
http://www.globespan.net

---

From: Grenville Armitage <[email-masked]>
Date: Thu, 11 May 2000 09:14:30 -0700

Rohit Chhapolia wrote:
	[..]
> through it? It may lead to degradation of service for the EF class.

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/
Bell Labs Research Silicon Valley

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 May 2000 15:08:58 -0500

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

---

From: Scott Brim <[email-masked]>
Date: Fri, 12 May 2000 09:50:22 -0700

If you want different treatment you should use different tunnels (until we
figure out something better).