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

From: "Chen, David" <[email-masked]>
Date: Tue, 29 May 2001 09:58:49 -0400

Eliazer Elwin,
It seems the meaning of "flow" need to be defined to further discussion.
By "bundle" all "flow session"s into one tunnel, I mean
each PPP session is a flow session and this fits what you understand.

Divide single PPP session into multiple l2tp session will be
better than the MP over single (or multiple) l2tp session?

Some have express this oppion.

The packet classification in diff-serve and PHB do not change
at all.  

What Quality is added to the service?

--- David

-----Original Message-----
From: Elwin Eliazer [mailto:[email-masked]]
Sent: Friday, May 25, 2001 8:58 PM
To: Chen, David; 'Umesh Sirsiwal'; [email-masked]
Cc: [email-masked]
Subject: RE: Qos and L2TP (was: Do we want a new L2TP Header?)

Chen David,

The bundling of L2TP (flow) sessions could not
be achieved through L2TP tunnels, because there
is one L2TP session for one PPP session as of now,
and we can have multiple PPP sessions across the
same LAC and LNS.

Fundamentaly, the draft-elwin-l2tpext-diffserv-00.txt
describe a mechanism to divide a PPP session into
multiple L2TP sessions, and have an association among
these sessions; the main application for this 
being QOS.

Just for clarification.

cheers,
Elwin.

--- "Chen, David" <[email-masked]> wrote:
> 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/
> > 

=====
-------
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: Tue, 29 May 2001 09:43:20 -0700 (PDT)

David,

I am not getting it clear what is your question
or concern or suggestion is here.

Regarding QOS, what is provided in the draft is
a means to have flow based differentiated services.

And a 'flow' can be defined as a collection of
packets that can be grouped together, over which
a similar treatment needs to be given.

- Elwin.

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