Subject: RE: Qos and L2TP (was: Do we want a new L2TP Header?)

From: Wei Luo <[email-masked]>
Date: Tue, 22 May 2001 12:55:55 -0700

At 03:17 PM 5/22/2001 -0400, Umesh Sirsiwal wrote:
>Let me summarize the discussion we had about this issue:
>
>1. LAC/LNS policy can be used to apply proper algorithm
>and DSCP for flows within a session. We may not be willing
>to copy inner DSCP to outer header since it is LAC
>which actually performs packet classification in a lot
>of cases. We do not want to propagate customer choosen
>DSCP to core of the network.

Why would you rule out this option completely?  Whether to reflect the 
inner DSCP is a policy of the LAC, the service provider can decide whatever 
they want.  It's a pure local matter, more precisely an operational 
matter.  Implementations should just provide tools for the network operator.

>2. draft-ietf-l2tpext-ds-03.txt provides a way to negotiate
>DSCP for the session.
>
>Isn't there some contradiction here? It will seem to be that
>if we follow draft-ietf-l2tpext-ds-03.txt there is no way to
>distinguish between different flows within traffic since all
>use the same DSCP... It seems to be this draft is incomplete
>in that respect. Shouldn't it be exnteded to negotiate mutiple
>DSCPs between LAC and LNS?
>
>Am I missing somehting?

Probably.  Even though the different types of traffic come from the same 
user, it doesn't necessarily mean there is only one session allowed for 
each user.  If the user want to DS at that fine level, i.e. different QoS 
for each flow, the better options is to create multiple sessions to the 
LNS, and each carries a particular type of flow and negotiates different 
QoS parameters.

Keep in mind that per-flow QoS is not scalable regardless what signaling 
protocol you use.  That's why its deployment is very rare.  For example, 
RSVP has a whole lot more to offer in terms of per-flow QoS, but it almost 
became extinct (until MPLS-TE revived it and gave it a new role).

---Wei

---

From: Evan Caves <[email-masked]>
Date: Tue, 22 May 2001 15:59:01 -0700

If PPP had a QOS attribute in each frame then the problem becomes
simple(r) :-).

evan
-

---

From: Ignacio Goyret <[email-masked]>
Date: Tue, 22 May 2001 15:56:11 -0700

>If PPP had a QOS attribute in each frame then the problem becomes

That's a great idea! It could easily be done with an outer header:

   00 xx qq

xx  a new protocol number, meaning "PPP QOS".
qq  the qos attribute

This header could be immediately followed by the usual PPP headers.
Something like this (assuming no ACFC/PFC):

  FF 03 00 xx qq 00 21 45 ....
or 
  FF 03 00 xx qq 00 FD ....

This would solve most issues. Now the only remaining issue is the
already installed base. :-(

---

From: James Carlson <[email-masked]>
Date: Wed, 23 May 2001 07:58:17 -0400 (EDT)

> If PPP had a QOS attribute in each frame then the problem becomes

It's already there.  See RFC 2686.

-- 
James Carlson, Internet Engineering       <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677