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

From: "Umesh Sirsiwal" <[email-masked]>
Date: Tue, 22 May 2001 15:17:33 -0400

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.

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?

-Umesh

-----Original Message-----
From: W. Mark Townsley [mailto:[email-masked]]
Sent: Tuesday, May 22, 2001 2:59 PM
To: Chen, David
Cc: Umesh Sirsiwal; [email-masked]
Subject: Qos and L2TP (was: Do we want a new L2TP Header?)

"Chen, David" wrote:
> 
> How does this relate to the L2tp header?

Doesn't really, but threads get off track sometimes :-)

> 
> The QoS enforcement seems only to do with the media (UDP, ATM...)
> For IP as the media, DS seems make sense to differentiate
> different tunnel/session's traffic characteristic between LAC and LNS.
> 
> How about other media?
> 
> --- David
> 
> -----Original Message-----
> From: W. Mark Townsley [mailto:[email-masked]]
> Sent: Tuesday, May 22, 2001 12:16 PM
> To: Chen, David
> Cc: 'Umesh Sirsiwal'; [email-masked]
> Subject: Re: Do we want a new L2TP Header?
> 
> Yes, via draft-ietf-l2tpext-ds-03.txt, L2TP signalling may be used to
> identify a DSCP for a session. As for flows within that session, you
may
> identify these and apply them to your policy however you wish. One
> popular feature is to "reflect" the inner DSCP to the outer header.
You
> could also classify traffic based on ports or your favorite traffic
> classification algorithm and apply this to your outer IP header. This
> policing/enforcing is really a vendor-specific implementation issue.
> 
> - Mark
> 
> "Chen, David" wrote:
> >
> > To make IP QoS works, it has two major functions.
> > One is setup/modify/teardown negotiation;
> > the other is policing/enforcing.
> >
> > This darft seems only provide the first phase.
> > It seems rely on the L2tp over UDP to modify
> > outer IP header's DS to perform the policing/enforcing.
> >
> > --- David
> >
> > -----Original Message-----
> > From: Umesh Sirsiwal [mailto:[email-masked]]
> > Sent: Tuesday, May 22, 2001 11:02 AM
> > To: W. Mark Townsley; [email-masked]
> > Subject: RE: Do we want a new L2TP Header?
> >
> > I will agree that a fixed header would make microcoded
> > engines lot easier to implement and will improve overall
> > performance.
> >
> > When we are at it... I have another question with respect
> > to L2TP. That involves ineraction of L2TP with
> > draft-ietf-l2tpext-ds-03.txt.
> > This draft addresses issue with respect to DS based differentiation
> > between different tunnels which means differentiation
> > between different subscribers. In a QoS enabled world
> > it is essential to differentiate between differnt types
> > of traffic from the same subscriber. That can be used
> > for VoIP, video delivery, etc.
> >
> > I know it is somewhat confusing with respect to layering
> > violations. However, I do not know where else to address
> > this issue. L2TP provides L2 tunneling, and should also
> > address issues with respect to differentiation of different
> > types of traffic in a tunnel.
> >
> > Comments?
> >
> > -Umesh
> >
> > -----Original Message-----
> > From: W. Mark Townsley [mailto:[email-masked]]
> > Sent: Monday, May 21, 2001 3:00 PM
> > To: [email-masked]
> > Subject: Do we want a new L2TP Header?
> >
> > L2TP currently has two classes of headers. (1) Those defined in
RFC2661,
> > and (2) those defined in draft-ietf-l2tpext-l2tphc-03.txt. Within
each
> > class, we have more than one header we have to recognize, based on
the
> > bits set in the beginning of the header or signaling that occurred
at
> > session establishment (particularly for the case of l2tphc).
> >
> > Even in light of this complexity, we enjoy exceptional
interoperability
> > among so many independent implementations that I lost count a long
time
> > ago. Also, like many protocols, the variability defined in the
original
> > specification has begun to converge into a more static subset of
fields
> > that we most often see in L2TP deployments today. Rather than
letting
> > nature continue to take its course for better or worse and require
all
> > new implementations to continue to include code for what are
> > increasingly rare expectations, I would like to get a sense of the
group
> > as to whether we should entertain definition of a new, fixed, header
> > with L2TP. Many of you have approached me offline about this, so I
> > thought that bringing the idea to the list would be appropriate.
> >
> > An easy transition to a new header would be aided by the signaling
that
> > we all support. We would simply advertise support for the new header
at
> > tunnel and session establishment, much like we do for l2tphc. The
hope
> > would be that, one day, all implementations would converge on this
> > header and that our hardware, ASICs, etc. only have to support this
> > rather than than the various headers we have today that are
identified
> > on a per-packet basis.
> >
> > In the past, I have rejected a major change like this, citing that
any
> > improvement in the header would not be worth disrupting our existing
> > interoperable codebases. However, with the open-heart surgery that
is
> > ongoing in RFC2661 to separate the L2TP tunneling plane from PPP and
> > more and more people pushing L2TP processing down into microcode and
> > ASICs (essentially requiring a rewrite of our data paths anyway), I
> > wonder now is the time to go ahead and apply what we have learned
over
> > the past 5 years with hope of paving a way for the next 5 years.
> >
> > I have a set of ideas that have culminated over the past couple of
years
> > that I would be happy to post to the list to initiate discussion,
but
> > only if there is interest and consensus that definition of a new
header
> > for L2TP is a Good Thing to do.
> >
> > Comments appreciated,
> >
> > - Mark

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 22 May 2001 12:20:52 -0700

> DSCPs between LAC and LNS?

How would you then classify different flows within each session for
application of the negotiated DSCPs?

---

From: Elwin Eliazer <[email-masked]>
Date: Wed, 23 May 2001 09:04:37 -0700 (PDT)

Hi,

There are different cases to be considered, when doing
L2TP diffserv:

  - where is the diffserv cloud with respect to the
    L2TP edges. Based on where the diffserv edge
    starts, classification can be done accordingly.
  - how many diffserv domains are involved
  - is the tunnel packet belonging to the same
diffserv
     domain as the payload packets
  - do we need to have same diffserv values for
    both the directions of traffic. The 
    draft-ietf-l2tpext-ds-03.txt makes it this
    way, bbut that need not be the case.
  - how to handle multiple flows within the same
    PPP session. For example voice and data traffic
    can go thru the same PPP session, but will need
    differentiated services.

Please read draft-elwin-l2tpext-diffserv-00.txt
where we have tried to address some of the issues,
mentioned above, that Umesh is also pointing. We are
updating this draft now, so please do email your
concerns in this area, and you are also welcome to
join in this effort.

I would also appreciate to hear your feedback on this
draft.

cheers,
Elwin.

> > > > for L2TP is a Good Thing to do.

=====
-------
Elwin Stelzer Eliazer
Corona Networks
-------

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/