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

From: "Chen, David" <[email-masked]>
Date: Thu, 31 May 2001 11:54:19 -0400

To create new l2tp session and forwarding packets to a "correct" session,
it will required sniff every PPP packets at LAC or
as you infered that another protocol/application "embeded" in the
LAC to start a new session.  These other protocol/applications will
also decide what sessions the incoming packet from a PPP session will be
forward to.

If all these is to modify DS in the outer IP header, it seems not adding any
new
quality service to existing one since the l2tp session are not visible to
everyone
HOP the packet went through.  It does not change PHB.

1) this is true if LAC only copy inner DS to outer DS.
2) This is a chaos if having different interpretation/mapping from
	inner DS to outer DS.
  i) Image what the traffic originator (user) and receiver will respond 
	when underlining carrier change what both has intended for.    
	No more DS QoS for two PPP end points.
  ii) Image this kind of LAC exist at least two of em along the HOPs. 
	(i.e. tunnel in a tunnel) The configuration complexity will be in
exponential number.

What is the value added to l2tp protocol for the expense to increase the
complexity (if not impossible) for both acrossing above l2tp comm layer and
configuration?

--- David

-----Original Message-----
From: Umesh Sirsiwal [mailto:[email-masked]]
Sent: Thursday, May 31, 2001 11:29 AM
To: Chen, David; Elwin Eliazer; [email-masked]
Cc: [email-masked]
Subject: RE: Qos and L2TP (was: Do we want a new L2TP Header?)

Comments below....

> 
> Umesh,
> If the reason for single PPP session over muti-l2tp session is QoS,
> it is concerned that the LAC has to "know" the PPP's payload.

Well! if we have the capability to split a PPP session one can find
several ways to use it. QoS being once of them. Yes! LAC has to know
PPP's payload. Anything wrong in it? Ofcourse in this case LNS has
to trust LAC. Trust relationship is a network deployment issue. Let
Network Operators worry about that. 

> Further more, the PPP has to classify its encapsulated 
> payload packets,
> so that LAC have this correct information (to start a new 
> l2tp session and
> forward all alike PPP packet to this new l2tp data channel)
> 
> Does the LAC has to sniff on the PPP's payload to decide a new
> l2tp session?

Well! how LAC decides to start a new session is implementation
dependent. It
can be sniffinf packets, under control of SoftSwitch, or a video
delivery
server, or some other mechanism.
As with most of QoS related issues, trigger for packet classification
and 
actual packet classification algorithm is implementation dependent.

> 
> After new l2tp session is established, there are two l2tp sessions, 
> will the LAC sniff on all packets in this PPP session and 
> forwarding to
> one of these two session according to its  QoS characteristics?
> 
> It seems more difficult when
> the PPP's LCP negotiated compression for this session with a 
> initial l2tp
> session
> running.  

Once again implementation dependent issue. LNS can always refuse
to negotiate compression if it wants to take advantage of split
sessions. Is that a big deal? This will not be the only LNS which
will refuse packet compression negotiation!

-Umesh
> 
> --- David
> 
> 
> -----Original Message-----
> From: Umesh Sirsiwal [mailto:[email-masked]]
> Sent: Monday, May 28, 2001 8:13 PM
> To: Chen, David; Elwin Eliazer; [email-masked]
> Cc: [email-masked]
> Subject: RE: Qos and L2TP (was: Do we want a new L2TP Header?)
> 
> 
> David...
> Without using draft-elwin-l2tpext-diffserv-00.txt how can
> one implement breaking one PPP session in multiple L2TP
> sessions? How about those LCP packets? Where should they
> go? How do we convey that a new L2TP session uses LCP 
> parameters and authentication credentials already negotiated?
> Don't we need some relationship between these sessions? 
> They are not independent sessions. There is some type of 
> "L2TP session bundling" involved here. This is not just
> an implementation issue. Since we need  a way in protocol
> to identify "session bundle" to which new session belong.
> 
> I am not saying "session bundling" is the perfect way of 
> solving this problem, however we need a way to define
> relationship between L2TP sessions from the same PPP 
> connection.
> 
> Once we have such a support in the protocol it will be easy
> to implement QoS since every one of these sessions can
> have defined QoS value. In that QoS classifiers can be based on
> local policies.
> 
> -Umesh
> 
> 
> > -----Original Message-----
> > From: Chen, David [mailto:[email-masked]]
> > Sent: Thursday, May 24, 2001 10:06 AM
> > To: Umesh Sirsiwal; Chen, David; Elwin Eliazer; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: Qos and L2TP (was: Do we want a new L2TP Header?)
> > 
> > 
> > Traffic classification value as an attribute of l2tp 
> sessios is good.
> > This is the least effort for the "best effort" QoS in l2tp.
> > As for each "flow" as an session, it is still implementation 
> > dependant.
> > 
> > I can aggregate all "flow" sessions into one tunnel and this 
> > tunnel only
> > for a particular user.
> > Or, I can aggreate all same class of traffic from different 
> > user into one
> > single session.
> > For each session in this tunnel has different QoS characteristics.
> > 
> > About PHB (per-hop behavior), it will "ask" all hops treat 
> > this IP packet as
> > indicated
> > in the DS - with uniform interpretation.
> > Besides PHB, the packet can not exclude the possiblity that 
> it will go
> > through more than one tunnel. These "tunnel"s has to do the 
> > same as PHB.
> > 
> > The QoS policing/enforcement between LAC and LNS depends
> > on the HOPs in the flow.    
> > It is depends on the l2 media that will "honor" this QoS 
> > contract between
> > LAC and LNS.
> > 
> > If the l2 media is ATM, the mapping from DS to ATM QoS scheme 
> > (and back) is
> > as critial as PHB.
> > 
> > I'am wondering why ST2 fails. :-)
> > 
> > --- David
> > 
> >     
> > 
> > 
> > -----Original Message-----
> > From: Umesh Sirsiwal [mailto:[email-masked]]
> > Sent: Wednesday, May 23, 2001 7:21 PM
> > To: Chen, David; Elwin Eliazer; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: Qos and L2TP (was: Do we want a new L2TP Header?)
> > 
> > 
> > I tend to agree with Wei Luo and 
> draft-elwin-l2tpext-diffserv-00.txt 
> > that the correct way to solve differentiated service between 
> > different 
> > flows is to create a new session for QoS profile. 
> > That way local LAC/LNS policies can be used to decide the 
> scheduling 
> > algorithm and each QoS profile session can be scheduled 
> > properly through
> > 
> > the network. However currently there is no way of creating such 
> > flow session. This mechanism will need some concept of 
> "base session" 
> > and "flow session". "Base session" is where all LCP messages are
> > exchanged. 
> > This will carry all the normal traffic as well. A "flow session" is
> > created on demand when a new QoS profile traffic needs to 
> be carried.
> > This demand has a local origin as well. Example scenerios for this
> > may be a soft switch asking LAC to create a new flow in 
> case the user
> > wants to make a phone call. 
> > 
> > This mechanism is layer 2 independent.
> > 
> > As far as scalability of the solution is concerned, it 
> > does not need per flow queueing in the core. It is still
> > aggregate queuing mechanism rather then per flow queueing.
> > However this may will result extra control plane messages
> > exchanged when a new flow is created.
> > 
> > 
> > Comment?
> > -Umesh
> > 
> > > -----Original Message-----
> > > From: Chen, David [mailto:[email-masked]]
> > > Sent: Wednesday, May 23, 2001 1:41 PM
> > > To: 'Elwin Eliazer'; [email-masked]; Umesh Sirsiwal
> > > Cc: Chen, David; [email-masked]
> > > Subject: RE: Qos and L2TP (was: Do we want a new L2TP Header?)
> > > 
> > > 
> > > It is not a bad idea to have "flow id" list as one of the 
> > > l2tp session's
> > > attribute.
> > > However, it is possible to have multiple user using the same 
> > > type of flow
> > > within 
> > > the same l2tp session.  (e.g. 10 Movie-on-damand user 
> > > whatching the same
> > > Movie channel)
> > > These 10 hosts do not have the same QoS classification.
> > > It seems need further put (the user) L2tp's payload ip 
> > > address into the
> > > the l2tp session's attribute.
> > > To make thing more complicate, the user's movie flow is from 
> > > different 
> > > movie server that has different QoS classification (depends 
> > > on the content) 
> > > So we have to add the server's realm info into the l2tp session's
> > > attribute...
> > > 
> > > Also, when wathch movie and ad., it has very light traffic 
> > > from user to
> > > server the
> > > QoS classification is different from that of the opposite 
> > direction.  
> > > It is good to have separate DS for  both direction of traffic 
> > > between LAC
> > > and LNS in the same l2tp session.
> > > 
> > > After all this, we still rely on the "cloud" honor the DS 
> > > that inject the
> > > packet from the "edge".
> > > 
> > > --- David
> > > 
> > > 
> > > -----Original Message-----
> > > From: Elwin Eliazer [mailto:[email-masked]]
> > > Sent: Wednesday, May 23, 2001 12:05 PM
> > > To: [email-masked]; [email-masked]
> > > Cc: [email-masked]; [email-masked]
> > > Subject: Re: Qos and L2TP (was: Do we want a new L2TP Header?)
> > > 
> > > 
> > > 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.
> > > 
> > > --- "W. Mark Townsley" <[email-masked]> wrote:
> > > > 
> > > > 
> > > > 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.
> > > > > 
> > > > > 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?
> > > > 
> > > > How would you then classify different flows within
> > > > each session for
> > > > application of the negotiated DSCPs?
> > > > 
> > > > > 
> > > > > 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
> > > 
> > > 
> > > =====
> > > -------
> > > Elwin Stelzer Eliazer
> > > Corona Networks
> > > -------
> > > 
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Yahoo! Auctions - buy the things you want at great prices
> > > http://auctions.yahoo.com/
> > > 
> > 
>

---

From: Elwin Eliazer <[email-masked]>
Date: Thu, 31 May 2001 14:23:29 -0700 (PDT)

David,

What is mentioned is a means that can be used in
different ways. How we use it varies, and 
having multiple sessions will help in
having differentiated services. It is still not clear
on what your argument is, and what you feel as
complex here?

cheers,
Elwin.

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

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/