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

From: "Rajesh Sundaram" <[email-masked]>
Date: Fri, 12 May 2000 14:34:43 -0700

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) 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.

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]]
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:
>         [..]
> > 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.
> 
> 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
> 
> _______________________________________________
> 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: Fri, 12 May 2000 16:33:57 -0700

> Rajesh Sundaram wrote:
	[..]
> 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.

Naturally - by construction, since the "use a single tunnel like
a wire" is going to be a subset of any other scheme that involves
more than one tunnel. Certainly when I suggested simply using a
fixed DSCP for each L2TP tunnel I did not intend that to be
interpreted as "you can only have one tunnel".

>  I'd appreciate comments that help us make a decision on this.

Implement something that allows flexible mapping rules.

Perhaps it would be easier to codify rules if we keep in mind that
the DSCP for the outer (tunneling) IP header is really only providing
service to the PPP session being tunneled. The PPP session(s) are
then (in the abstract at least) providing the 'wire' for the (many)
IP flows being mapped onto each PPP session. Now, as I understand
it, the premise of this thread is that you dont want reordering of
PPP frames within a single session. Simple conclusion - when an L2TP
tunnel supports a distinct PPP session, that tunnel's outer IP header
ought to have a fixed DSCP (or at least a DSCP from a PHB Group that
enforces non-reordering). Beyond that, how you choose to map
particular classes of tunneled IP traffic onto particular PPP
sessions is another discussion entirely....

cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley

---

From: Evan Caves <[email-masked]>
Date: Fri, 12 May 2000 16:57:45 -0700

> a) Mark the outer header packets of all tunneled packets with a
> uniform codepoint.
> 
> 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.

For L2 tunneling protocols this seems to be the only option. For example
an L2TP session would be created within a tunnel that provides the per
hop
behavior for a particular dialin user based on some pre-defined policy.
There
may be multiple tunnels between the same two endpoints, each providing a
different service level. However there could be microflows within the
session
which themselves are marked differently but are given the outer mark
PHB.
The microflows within the session cannot be 're-routed' down a different
tunnel that maps to the appropriate PHB. As an aside L2TP
implementations (at
least at the LAC ingress to the tunnel) may 'snoop' the PPP control
frames
in order to manage payload sequencing but usually do not goes as far as
'snooping' the IP header.

evan
-

> 
> b) Create a (small) set of multiple tunnels, each tunnel getting a
> fixed codepoint, that is distinct from other tunnels. All packets on a
> 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.
> 
> 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
>

---

From: Ignacio Goyret <[email-masked]>
Date: Fri, 12 May 2000 18:26:22 -0700

At 04:57 PM 5/12/00 -0700, Evan Caves wrote:
>As an aside L2TP implementations (at least at the LAC ingress to the
>tunnel) may 'snoop' the PPP control frames in order to manage payload
>sequencing but usually do not goes as far as 'snooping' the IP header.

And even if they attempted to, they will fail miserably sooner or later
because of things like PPP compression, encryption, and MP (you may be
looking at just one link out of many and you only look at one fragment
of the whole PPP packet).

-Ignacio

-----------------------------------------------------------------------
Ignacio Goyret, Sr. Software Engineer             Voice: (510) 747-2823
Lucent Technologies                               FAX:   (510) 747-2859
1701 Harbor Bay Parkway, Alameda, CA 94502