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

From: "Chen, David" <[email-masked]>
Date: Fri, 1 Jun 2001 09:51:31 -0400

Elwin,
I assume you mean Ns and Nr in the l2tp header in l2tp data channel.
As you know, these are not visible to PHB;
therefore "the sequence numbers are enabled" does not change PHB.
In addition, the l2tp data channel does not include flow control.
These (Nr and Ns) are just for pakcet drop/reordering detection
and not affact QoS.  Although the LAC and LNS can implement flow control,
it will not be better than TCP.
Further more, since l2tp encapsulate PPP/IP and the IP does NOT
guarantee delivery packet in order and no loss, 
It does not improve iner IP payload's QoS even the 
l2tp guarantee deliver packet in order and no loss.

--- David

-----Original Message-----
From: Elwin Eliazer [mailto:[email-masked]]
Sent: Thursday, May 31, 2001 5:13 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Qos and L2TP (was: Do we want a new L2TP Header?)

David,

Going according to the reflection method you have
mentioned, have you ever thought what happens when
the sequence numbers are enabled?

- Elwin.

--- "Chen, David" <[email-masked]> wrote:
> Elwin,
> In the context of diff-serve,
> the IP packet is differentiated by this DS.
> At each HOP, the IP packets have same DS will be
> treated the same.
> For the case of UDP as L2tp's media,
> the outer IP's DS is used as classification.
> Does not matter what l2tp session is in side this IP
> payload.
> 
> Hence, how many l2tp session or which l2tp session
> is not visible at each
> HOP.
> For a good practice, as has been done, is copy the
> inner IP DS to outer IP
> DS 
> to preserve the traffic originator's intent.
> No co-relation to which l2tp session is used.
> 
> Why  bother having different l2tp session, that have
> same effect on each
> HOP?
> 
> If you consider having different outer IP DS from
> inner IP DS,
> it has been said in this thread.
> 
> --- David
>  
> 
> -----Original Message-----
> From: Elwin Eliazer [mailto:[email-masked]]
> Sent: Tuesday, May 29, 2001 12:43 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Qos and L2TP (was: Do we want a new
> L2TP Header?)
> 
> 
> 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.
> 
> --- "Chen, David" <[email-masked]> wrote:
> > 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/
> 
> 
> =====
> -------
> 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!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

---

From: "Chen, David" <[email-masked]>
Date: Fri, 1 Jun 2001 10:13:21 -0400

Elwin,
A question to you is that
why having mutiple sessions for a single PPP session will help DS QoS
since the l2tp header is not visible to PHB?

Please refer to RFC2475 and RFC2983 for PHB.

--- David

-----Original Message-----
From: Elwin Eliazer [mailto:[email-masked]]
Sent: Thursday, May 31, 2001 5:23 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Qos and L2TP (was: Do we want a new L2TP Header?)

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.

--- "Chen, David" <[email-masked]> wrote:
> 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
> 
> 
> 
> Sent: Thursday, May 31, 2001 11:29 AM
> To: Chen, David; Elwin Eliazer; [email-masked]
> Cc: [email-masked]
> 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
> > 
> > 
> > Sent: Monday, May 28, 2001 8:13 PM
> > To: Chen, David; Elwin Eliazer; [email-masked]
> > Cc: [email-masked]
> > 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
> > 
> > 
> > > Sent: Thursday, May 24, 2001 10:06 AM
> > > To: Umesh Sirsiwal; Chen, David; Elwin Eliazer;
> [email-masked]
> > > Cc: [email-masked]
> QoS in l2tp.
> implementation 
> > > dependant.
> tunnel and this 
> > > tunnel only
> from different 
> > > user into one
> QoS characteristics.
> hops treat 
> > > this IP packet as
> has to do the 
> > > same as PHB.
> this QoS 
> > > contract between
> ATM QoS scheme 
> > > (and back) is
> service between 
> decide the 
> > scheduling 
> of creating such 
> concept of 
> > "base session" 
> LCP messages are
> A "flow session" is
> needs to 
> > be carried.
> flow in 
> > case the user
> concerned, it 
> is still
> new L2TP Header?)
> one of the 
> Movie-on-damand user 
> movie flow is from 
> classification (depends 
> the l2tp session's
> light traffic 
> the opposite 
> > > direction.  
> direction of traffic 
> honor the DS 
> new L2TP Header?)
> when doing
> to the
> We are
> welcome to
> on this
> about this
> may not be
> it is LAC
> classification in a
> way to
> will seem
> draft is
> new L2TP
> with the
> inner DSCP
> ports or
> to your
> first phase.
> L2TP with
> respect to DS
> That can
> where else
> tunneling, and
> headers. (1)
> header or
> for the
> implementations that
> into a
> would like
> would be
> etc. only
> we have
> of our
> way for
> list to
> consensus that
> great prices

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

---

From: "Umesh Sirsiwal" <[email-masked]>
Date: Sat, 2 Jun 2001 16:48:40 -0400

Black David and Jeff's mails further reinforce the point that it
is best for PPP sessions to be split in multiple L2TP session to
enable QoS. Unless somebody has an objection, we will like to 
revise draft-elwin-l2tpext-diffserv-00.txt and resubmit it.

Thanx,
-Umesh

> From: Jeff Mcadams [mailto:[email-masked]]
> Sent: Friday, June 01, 2001 9:08 PM
> To: [email-masked]
> Subject: Re: Qos and L2TP (was: Do we want a new L2TP Header?)
> 
> 
> Also sprach [email-masked]
> >As the author of RFC2983 and a co-author of RFC-2475, here's 
> the answer
> >... some QoS differentiation is based on packet reordering - the more
> >important packets are forwarded before the less important packets in
> >the queue.  If L2TP is enforcing ordering within a session, it will
> >undo this re-ordering for QoS, thereby making the QoS even worse than
> >it was to begin with (the more important packets now have to wait for
> >the less important ones that got worse forwarding treatment).
> 
> Not necessarily...though the potential is there.  Keep in 
> mind that the
> data sequencing is not reliable delivery.  If the QoS 
> re-ordering moves
> some higher priority packets in front of lower priority packets, the
> behavior of the end system receiving these (out of order) 
> packets is not
> exactly specified.  The system MAY (assuming I'm remembering all this
> correctly) buffer the packets to re-order them based on the sequence
> number, in which case your theory would be right, but it *might* also
> just accept the higher priority packets and then when the 
> lower priority
> packets come in, just drop them on the floor since they are out of
> order.  Now...I'll also agree that this is going to result in an even
> greater hit in throughput for the lower priority traffic than was
> originally contemplated by re-ordering the packets for QoS 
> reasons...but
> your original theory as to what will result is not *necessarily*
> correct.
> -- 
> Jeff McAdams                            Email: [email-masked]
> Head Network Administrator              Voice: (502) 966-3848
> IgLou Internet Services                        (800) 436-4456
>

---

From: "Chen, David" <[email-masked]>
Date: Mon, 4 Jun 2001 10:22:16 -0400

David,

Thanks for the explanation:
In the same DS domain could have two l2tp session that one requires 
deliver packets in order and the other is not.

If this is what it means in the 4.1 of RFC 2983, I have the following
argument:

For other tunneling protocol it MAY requires to a new "session" to
carry out different DS. (could be a crossing to different (virtual) DS
domain)

For l2tp tunneling, the l2tp header's sequencing bits are not visible to 
PHB, all the LAC and LNS (of the l2tp tunnel end-point)
need to perform to guarantee the "in order" DS is simply to change the outer
IP's DS.
Actually, to be more specific, the above l2tp layer changes the iner IP's DS

at LAC and LNS before entering l2tp session.  
These are "application" specific. (and no l2tp involved)

What QoS value is added to have a new l2tp session so that it can guarantee
the 
"in order" packet delivery. (it can be done without it anyway)

In addition, strict discussion on l2tp layer, 
here are two possible cases between l2tp's inner IP DS domain and
l2tp's outer IP DS domain.

1) The inner DS is the same as outer DS 
	-> no need for new session -	just copy inner DS to outer DS.
2) The inner DS is different from outer DS
	-> need new session (but...)
   1.	The inner DS is NOT "in order" but outer DS is "in order"
	-> Not a desired case (waste of resources)
   2. The inner DS is "in order" but outer DS in NOT "in order"
	-> Not a desired case 

Form above analysis, the case 1) is sufficient to carry out traffic
originator's
intent.
Hence, NO new l2tp session is required.  :-)

--- David

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 01, 2001 7:21 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Qos and L2TP (was: Do we want a new L2TP Header?)

As the author of RFC2983 and a co-author of RFC-2475, here's
the answer ... some QoS differentiation is based on packet
reordering - the more important packets are forwarded before the less
important packets in the queue.  If L2TP is enforcing ordering within a
session, it will undo this re-ordering for QoS, thereby making the QoS
even worse than it was to begin with (the more important packets now
have to wait for the less important ones that got worse forwarding
treatment).
Hence one can either have ordering-based QoS differentiation or L2TP
enforcement of ordering in a single L2TP session, but not both.  Multiple
L2TP sessions allows ordering-based QoS differentiation across L2TP
sessions, and L2TP enforcement of ordering within each L2TP session.

A more detailed explanation of this can be found in Section 4.1 of RFC 2983.

--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: "Chen, David" <[email-masked]>
Date: Mon, 4 Jun 2001 10:34:49 -0400

I agree that the packet latency, reordering and dropping are
corelated in the network, they are not orthogonal.
Reordering is due to the classification and prioritizing the packet to
solve the latency (and dropping).
However, the packet dropping cause others retrasmitting and congest the
network more.....

Who likes to solve this problem once for all?  :-)

--- David

-----Original Message-----
From: Jeff Mcadams [mailto:[email-masked]]
Sent: Friday, June 01, 2001 9:08 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Qos and L2TP (was: Do we want a new L2TP Header?)

>As the author of RFC2983 and a co-author of RFC-2475, here's the answer

Not necessarily...though the potential is there.  Keep in mind that the
data sequencing is not reliable delivery.  If the QoS re-ordering moves
some higher priority packets in front of lower priority packets, the
behavior of the end system receiving these (out of order) packets is not
exactly specified.  The system MAY (assuming I'm remembering all this
correctly) buffer the packets to re-order them based on the sequence
number, in which case your theory would be right, but it *might* also
just accept the higher priority packets and then when the lower priority
packets come in, just drop them on the floor since they are out of
order.  Now...I'll also agree that this is going to result in an even
greater hit in throughput for the lower priority traffic than was
originally contemplated by re-ordering the packets for QoS reasons...but
your original theory as to what will result is not *necessarily*
correct.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

---

From: [email-masked]
Date: Mon, 4 Jun 2001 16:57:07 -0400

> If this is what it means in the 4.1 of RFC 2983, I have the following

I'm afraid you've missed the point.  The scenario to consider is
one in which all the l2tp sessions in parallel are required to deliver
packets in order, but packets in different sessions can be reordered.
This cannot be done in a single l2tp session that is required to
deliver in order for obvious reasons, and trying to do so results in
l2tp causing potentially serious QoS damage when it undoes
the reordering (across microflows, not within a single microflow)
in a single session.  The potentially serious QoS damage is that
the rate of delivery of the least favored traffic within the l2tp
session governs the rate of delivery of all traffic within the session,
which is generally NOT what one wants when setting out to do
QoS differentiation.

The class of solution you're proposing gives up order-based
QoS differentiation between l2tp endpoints by marking traffic
in a fashion that no useful ordering QoS differentiation can take
place within an l2tp session.  This works fine, but may not
be what was desired.

--David

> From:	Chen, David [SMTP:[email-masked]]
> Sent:	Monday, June 04, 2001 10:22 AM
> To:	[email-masked]'; Chen, David
> Cc:	[email-masked]

---

From: "Chen, David" <[email-masked]>
Date: Mon, 4 Jun 2001 18:22:44 -0400

David,
Can you explain more about this scenario that will help DS QoS?
"The scenario to consider is
one in which all the l2tp sessions in parallel are required to deliver
packets in order, but packets in different sessions can be reordered."

It seems to say:
All l2tp sessions in a l2tp tunnel are required to deliver packets in order,
but (SOME) packets in different l2tp sessions in the same l2tp tunnel can be
reordered."

In other words, some packets in a l2tp session require deliver in order but
some packets in this same l2tp session do NOT require deliver in order?

(Therefore, need to split one l2tp session into two that one will deliver
packets in order and
the other l2tp session will not)

Looks like it is the same scenario as I have argumented.

Also, I can not agree with your statement that
"The potentially serious QoS damage is that
the rate of delivery of the least favored traffic within the l2tp
session governs the rate of delivery of all traffic within the session,..."

This is exactly what I like to know how this can happen since the l2tp
session
header is not visible to the PHB?

The rate of delivery of the least favored traffic has nothing to do the
l2tp session at each HOP - only DS of this particular packet matters in the
classification.  How can it governs the rate of delivery of all traffic
within the same l2tp session if each every packet in this same l2tp session
have its on inner DS 
(and same outer DS)?
It seems the only explanation is that at l2tp tunnel end point, for all
packets in the same l2tp session ,the inner DS has been uniformly changed to
a different outer DS.

Solution produces Problem is irrational.

Regards,

--- David

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 04, 2001 4:57 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Qos and L2TP (was: Do we want a new L2TP Header?)

--David

---

From: "Chen, David" <[email-masked]>
Date: Tue, 5 Jun 2001 09:10:19 -0400

Umesh,
As I have repeatedly pointed out that the
outer DS matters to PHB not the l2tp header.

Question to you is that
since the l2tp header is not visible to PHB, 
why the l2tp session or tunnel or Ns, Nr will affect DS's QoS?

--- David

-----Original Message-----
From: Umesh Sirsiwal [mailto:[email-masked]]
Sent: Monday, June 04, 2001 7:18 PM
To: Chen, David; [email-masked]
Cc: [email-masked]
Subject: RE: Qos and L2TP (was: Do we want a new L2TP Header?)

> header is not visible to the PHB?

I am afraid you are missing the complete point here. The complete
argument
is not about inner IP header but is about outer IP header. To enable
differentiation of service between different type of traffic in the
same PPP session we need to have different DS bits in the "OUTER" IP
header. And that is subject to all packet re-routing issues and QoS
degradation
issues discussed in this thread so far.

-Umesh

---

From: "Chen, David" <[email-masked]>
Date: Tue, 5 Jun 2001 16:53:57 -0400

The L2tp's sequence numbers have no correlation to outer DS and PHB.
However, if someone like to have the best of both world:
It should be clear at LAC if the DS is enable and what is the DS domain
when it encapsulate the outer IP and DS.

If the DS is not available, LAC can send the Sequencing required AVP to
LNS...business as usual.

If the DS is enabled, the mapping from the l2tp's "delivery packet in
sequence"
to the DS should be done before encapsulate the packet with outer DS.

The mapping could be "simply copy inner DS to outer DS" or
"ask DS domain do not change my packet sequence".

One point, l2tp sequencing numbers are not visible to PHB.

--- David

-----Original Message-----
From: Jeff Mcadams [mailto:[email-masked]]
Sent: Tuesday, June 05, 2001 1:20 PM
To: Ignacio Goyret
Cc: [email-masked]
Subject: Re: Qos and L2TP (was: Do we want a new L2TP Header?)

Also sprach Ignacio Goyret
>At 01:03 PM 6/5/01 -0400, Jeff Mcadams wrote:
>>>   "The LAC may request that sequence numbers be present in data
>>>   messages via the Sequencing Required AVP (see Section 4.4.6). If
>>>   this AVP is present during session setup, sequence numbers MUST be
>>>   present at all times.

>>This works *IF* the LAC didn't include the sequencing required AVP.
>>That's a pretty big "if" there.  If the LAC includes sequencing
>>required, then the LNS doesn't have that option.

>Yes, but changing that part of the spec is *much* easier than trying to
>sniff PPP packets to determine the DS that may apply to them, or trying
>to establish separate L2TP sessions for distinct flows within the same
>PPP session. The former doesn't work under the usual conditions that
>are found out there and the latter requires LACs and LNSs that don't
>follow 2661.

So, then, we go back to the original reason for the sequencing required
AVP to be there...for upper layer protocols that can't tolerate silent
packet re-ordering.

Are you saying that we should sacrifice the ability to carry those
protocols reliably in order to pick up DS capabilities?  Or are you
suggesting another mechanism to carry them reliably that won't conflict
with DS?
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

---

From: [email-masked]
Date: Sat, 9 Jun 2001 03:06:17 -0400

Let's start with the RFCs ...

Here's the crucial sentence from Section 4.1 of RFC 2983:

   L2TP can be configured
   to restore the ingress ordering of packets at tunnel egress, not only
   undoing any differentiation based on reordering within the tunnel,
   but also negatively impacting the traffic (e.g., by increasing
   latency).

This is based on the following sentence from Section 5.4 of
RFC 2661:

   Rather, data
   messages may use sequence numbers to detect lost packets and/or
   restore the original sequence of packets that may have been reordered
   during transport.

So, suppose that L2TP is configured to require sequence
numbers and use them to restore the original sequence.
Consider a situation in which the L2TP session is
shared by a best effort flow (e.g.,
web surfing) and a high priority flow using EF or
overprovisioned AF (e.g., remote access to the order
entry program), and assume that packets are marked
with the appropriate DSCPs in their outer headers.

One way in which differentiated services can be delivered
is via separate queues at intermediate nodes, so that EF/AF
packets will in general bypass the best effort traffic,
and the best effort queues are sufficiently loaded/
occupied for this to make a visible difference.  In
this case, L2TP will restore the
original sequence order of the packets, thereby forcing
the high priority flow to wait for the best effort flow
that receives worse forwarding treatment.  This is because
the original interleaving of the high priority and best
effort flows is restored).  Needless to say, this is not
the desired outcome.

This can be avoided either by not using this differentiation
(e.g., send all traffic as best effort in the outer header),
OR by putting the two flows into separate L2TP sessions so
that when L2TP "restore[s] the original sequence", it
restores the original sequence of each flow (best effort
and the high priority), but does not restore the original
interleaved order in which those flows were transmitted.

This whole discussion is about the details of making the
second option possible in cases where it's not otherwise
feasible to put the two flows in separate sessions; in
contrast, other emails are either disabling l2tp sequencing,
or using the first solution where the same PHB is used for
all traffic, and hence there is no differentiation within
the L2TP tunnel.  Needless to say, there are situations in
which at least the latter is not acceptable.  As I'm not an
L2TP expert, I'll have to defer to others to explain why 
the L2TP modifications proposed in the draft are important
and useful, but this should be a sufficient diffserv
explanation.

--David 

> Sent:	Monday, June 04, 2001 6:23 PM
> > Actually, to be more specific, the above l2tp layer changes the iner
> IP's
> > DS
> >

---

From: "Chen, David" <[email-masked]>
Date: Mon, 11 Jun 2001 11:14:49 -0400

David,
Thanks for the explanation, and example.

Indeed, the quality of service is degraded for higher priority traffic
when the l2tp sequencing is on and the inner DS are 
different for packets in the same l2tp session.  

There is a third option for improving this situation
besides "disabling sequence number" or "having new l2tp session".

It is copying the inner DS to the outer DS and 
if someone insist provide DIPD (Differentiate In-order Packet Delivery) in a
l2tp session
(and change l2tp protocol), l2tp can simply provide different SNS (Sequence
Number Set)
for each flow in the session.
 
In your example, the SNS could be 1~10 for EF and 200~300 for AF.
Notice that, they even can have separate receive window for buffering. (10
for EF, 100 for AF)
When the LAC(or LNS) copying the inner DS to outer DS, it can put in the
sequence number
from the corresponding SNS.  

The 2nd option of "Having new l2tp session" will NOT be better than the 3rd
option 
presented here but consumes a lot more resources and protocol changes. :-)

Regards,

--- David

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, June 09, 2001 3:06 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Qos and L2TP (was: Do we want a new L2TP Header?)

   L2TP can be configured

   Rather, data

--David

---

From: "Chen, David" <[email-masked]>
Date: Tue, 12 Jun 2001 14:19:22 -0400

Eliazer,
As you know,
the router does not guarantee deliver IP packet in-order.
In addition,
 L2tp's payload is IP (with PPP in between) that itself do not guarantee
deliver pakcet in sequence why bother deliver in sequence?

Furthermore,
The IP "pakcet drop" and "packet in sequence" are related to the size of
re-ordering buffer at each HOP.  

How not above l2tp layer protocol can not hanlde packet out of sequence yet
 it can recover from packet drop?

If an application like delivery packet in sequence, it can use TCP/IP thus
the in-order packet delivery belongs to TCP's service layer - not l2tp.

Even so, when someone insist using l2tp sequence numbers:

the example I have presented is for LAN environment so I pick 100.
If someone like to TransPacific connection, the number may go up to 1024.
:-)
What is the right number for Highest DS and Lowest DS?

The point is, none is using 65535 to buffer packets in a single session 
and re-ordering for the sake of not dropping a single packet. 
(consider the bursty-ness it contributed to the QoS) 
Why not usig them fully? or expand the sequence numbers field to xxx bits?

It is better, in my opinion, than split new sessions, coordinate these
sessions 
and sniff on every PPP packet to "route" among these l2tp sessions. 
I am sure these are not in standard neither and involed other WG.

As we have analyzed, 
all you need is "in-order packet delivery" for a DS value.

Do you like to land?

--- David

-----Original Message-----
From: Elwin Eliazer [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 1:25 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Qos and L2TP (was: Do we want a new L2TP Header?)

Chen,

I share the concerns what Black David, Jeff Mcadams
and Umesh Sirsiwal have mentioned earlier; and the
draft to split PPP sessions into multiple L2TP
sessions addresses this.
 
I don't think dividing the sequence number space
as you have mentioned below, is a good way to solve
this ... and not sure whether you have given
considerable thought over this on-the-fly solution,
which anyway has to deviate from standards.
Consider a cable connection to LAC @ 10 Mbps.
A sequence number space of 100 will mean sequence
number wraps at every 57.6 usec * 100 = 5.76 msec.
That is unreasonable going over the Internet. 

Regarding complexity in implementation, i consider
the solution presented in the draft easier, more
clear, and flexible for extensions. 

regards,
Elwin.
 
--- "Chen, David" <[email-masked]> wrote:
> > All l2tp sessions in a l2tp tunnel are required to
> deliver packets in
> > order,
> > but (SOME) packets in different l2tp sessions in
> the same l2tp tunnel can
> > be
> > reordered."
> > 
> > In other words, some packets in a l2tp session
> require deliver in order
> > but
> > session governs the rate of delivery of all
> traffic within the
> > session,..."
> > 
> > l2tp session at each HOP - only DS of this
> particular packet matters in
> > the
> > within the same l2tp session if each every packet
> in this same l2tp
> > session
> > have its on inner DS 
> > (and same outer DS)?
> > packets in the same l2tp session ,the inner DS has
> been uniformly changed
> > to
> > a different outer DS.
> > 
> > > need to perform to guarantee the "in order" DS
> is simply to change the
> > > outer
> > > IP's DS.
> > > What QoS value is added to have a new l2tp
> session so that it can
> > > guarantee
> > > the 
> > > enforcement of ordering in a single L2TP
> session, but not both.
> > Multiple
> > > A more detailed explanation of this can be found
> in Section 4.1 of RFC
> > > 2983.
> > > 
> > > --David
> > >

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

---

From: "Chen, David" <[email-masked]>
Date: Wed, 13 Jun 2001 11:21:37 -0400

-----Original Message-----
From: W. Mark Townsley [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 7:30 PM
To: Evan Caves
Mark,

Somehow the email subject is linked again. :-)

I vote for the idea here.
Especially 5., it makes "fast-pass" faster. 
It also reduce resources for just doing this.

--- David

Cc: [email-masked]

<snip>

I have been mulling around in my head some way to make our sequencing
ability
more realistically match that which people actually need to use sequence
numbers
for. My thoughts are that:

1. A sequence field should always be present in the payload
2. That sequence field MAY set to zero on sending
3. Packets received with a sequence number of 0 MUST be processed as they
are
received
4. If either side identifies a packet that must be sent in sequence relative
to
other packets, it SHOULD have sequence numbers set. e.g. PPP control packets
SHOULD have sequence numbers set. Any MLP or CCP packets SHOULD have
sequence
numbers set.
5. The peer SHOULD NOT use the presence of sequence numbers on any received
packets as any indication that sequence numbers be sent. This is a certain
change from RFC2661. This requires that the LAC sniff packets if it wishes
to
try and set sequence numbers for particular frames.
6. It is up to the receiver as to whether or not to try and honor the
sequence
number of incoming packets with a sequence number other than 0. 

- Mark

---

From: "Chen, David" <[email-masked]>
Date: Fri, 15 Jun 2001 14:31:28 -0400

Help, anyone help,

I was strangled :-)

--- David

-----Original Message-----
From: Jeff Mcadams [mailto:[email-masked]]
Sent: Friday, June 15, 2001 12:52 PM
To: Chen, David
Cc: 'James Carlson'; 'Evan Caves'; [email-masked]
Subject: Re: Qos and L2TP (was: Do we want a new L2TP Header?)

Also sprach Chen, David
>I am wondering if anyone on this thread can make an example that
>out-of-order PPP control messages (very few cases) can break the PPP's
>state machine since most of the time the control messages are sent one
>at a time. (re-transmit only count one message event)

And if noone steps forward with proof that re-ordering causes control
messages real problems?  What are your intentions?  Declare that we
don't need sequence numbers at all in L2TP?

What are you shooting for so aggressively here?

Putting sequence numbers on PPP control protocols just isn't going to be
that big of a deal really...I can't imagine that there would be any need
to apply differing QoS to control protocol messages, so go ahead and
sequence them, there's virtually no downside to it.

I do hope that you don't plan to suggest that PPP control protocols
don't need sequencing so we can ditch sequence numbers altogether as you
have yet to address the point that I and James Carlson have made (don't
remember which of us made it first...probably him :) that there are
other protocols carried by PPP which are *definitely* harmed by
re-ordering, thus requiring sequence numbers, thus we have to maintain
that capability, thus you might as well use it for PPP control messages.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

---

From: "Chen, David" <[email-masked]>
Date: Tue, 19 Jun 2001 12:04:08 -0400

I vote for what had mentioned in the thread: 

-----Original Message-----
From: W. Mark Townsley [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 7:30 PM
To: Evan Caves
Cc: [email-masked]
Subject: Re: Qos and L2TP (was: Do we want a new L2TP Header?)

<snip>
5. The peer SHOULD NOT use the presence of sequence numbers on any received
packets as any indication that sequence numbers be sent. This is a certain
change from RFC2661. This requires that the LAC sniff packets if it wishes
to
try and set sequence numbers for particular frames."
<snip>

--- David

-----Original Message-----
From: W. Mark Townsley [mailto:[email-masked]]
Sent: Monday, June 18, 2001 11:10 PM
To: Jeff Mcadams
Cc: Evan Caves; Elwin Eliazer; [email-masked]
Subject: Re: Qos and L2TP (was: Do we want a new L2TP Header?)

Jeff Mcadams wrote:
> 
> Also sprach W. Mark Townsley
> >Evan Caves wrote:
> >> What I am saying is that I do not believe that raw PPP encapsulated
> >> IP frames need sequencing. In this case the inner DSCP can be copied
> >> to the outer DSCP if that is the local tunnel encapsulators policy.
> >> If this is the majority of traffic that needs differentiating then
> >> this MAY be sufficient. As already pointed out if you are doing
> >> something like CCP or MP below IP then the LAC can't do squat anyways
> >> about differentiation.
> 
> >I think that sums it up well.
> 
> >It would be nice to think that when we tunnel PPP, all we have to worry
> >about is being faithful to PPP's lowest common denominator of
> >requirements. The reality is that the necessary faithfulness is more
> >dependent upon what is being carried by PPP than the requirements of
> >PPP itself. IP/PPP without CCP/ECP/MPPE/MP makes up a large enough
> >portion of tunnelled PPP traffic that being able to operate without
> >sequence numbers for these packets is not insignificant.
> 
> Indeed...I think there's a decent consensus on that.  If we can make an
> easy change and get the ability to manipulate the DSCP on IP/PPP/L2TP
> packets (ie, no MP and all those mentioned) then that's a pretty
> significant win right there.
> 
> >> This behavior would have to change. The LAC and or LNS will need to
> >> determine which packets need sequencing on transmit and provide in
> >> order delivery on reception. Unsequenced packets are delivered
> >> immediately (and I suppose potentially bypassing out of sequence
> >> queued packets).
> 
> >Yes, that sounds like the basic idea to me.
> 
> Sounds reasonable.
> 
> >The good thing is that backwards compatibility issues should not be too
> >terrible to overcome here. Even if we have an implementation that
> >expects sequence numbers and does not receive them, most
> >implementations in the field that I have seen are lenient in this case
> >and accept the packets anyway.
> 
> Heh...having recently taken over maintenance of l2tpd for Linux...I
> shudder to think about whether it does this or not.  As Mark Spencer was
> pretty anal about most of his checks, I suspect l2tpd will drop packets
> when a sequence number is expected but not received.  

Given that this would mean potentially dropping several packets during the
race
condition of the LAC responding to the LNS's enabling or disabling of
sequence
numbers, this would be particularly evil. I seem to remember a discussion on
the
list some time ago that ended in a pretty clear indication that when packets
were received with or without sequence numbers against what was currently
expected, that they should be accepted anyway... 

> I'll look into it
> though...I did do some work with sequence numbers in the code
> though...as part of ripping out all the session flow control code.  I
> may actually have been a bit overzealous and ripped out *all* the
> sequencing handling code.  Heh...guess I better check on that!  :)

You wouldn't be the first.

> 
> *heads off to the cvs tree*
> --