Subject: RE: Incompatibility between Diffserv and PPP based tunneling protocols

From: Rajesh Kumar <[email-masked]>
Date: Wed, 10 May 2000 18:25:14 -0700

If you turn off reordering and sequencing (as these are optional
in l2tp) and let tcp handle these issues, l2tp should work
seamlessly. tcp would handle the reliability issues for each
microflow. (I don't know much about pptp).
But this works only for tcp. How about others - like udp? - that's
unreliable service anyway, so why try to introduce reliability
at the link layer?

Does that sound workable?

-----Original Message-----
From:	Rajesh Sundaram [SMTP:[email-masked]]
Sent:	Wednesday, May 10, 2000 4:33 PM
To:	[email-masked]; [email-masked]
Subject:	Incompatibility between Diffserv and PPP based tunneling protocols

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.
 << File: ATT00002.htm >>

---

From: Radhakrishna <[email-masked]>
Date: Thu, 11 May 2000 13:16:13 +0530

Same issue is there with GRE tunneling also. Turning off sequencing and
reordering is definetly one solution. But if sequencing is really required,
the reordering can be done based on DSCPs and hence multiple tunnels
are not required.

Regards,
.....RK

> From:	Rajesh Kumar [SMTP:[email-masked]]
> Sent:	Thursday, May 11, 2000 6:55 AM
> To:	'Rajesh Sundaram'; [email-masked]; [email-masked]
> Subject:	[Diffserv] RE: Incompatibility between Diffserv and PPP
> based tunneling protocols
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Scott W Brim <[email-masked]>
Date: Fri, 12 May 2000 17:32:46 -0700

At 14:34 05/12/2000 -0700, Rajesh Sundaram wrote:
>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.

If you're just distinguishing according to diff-serv, you want at most a 
tunnel per per-hop scheduling class (not PHB).  There are other 
multipliers which might come into play, though.  For example, if you have 
VPNs you might need to a way to distinguish them (e.g. by using different 
tunnels) in order to do fair sharing for your customers.  The complexity 
of what you need to do depends directly on the complexity of the service 
differentiation you want to deliver.