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

From: "Umesh Sirsiwal" <[email-masked]>
Date: Thu, 14 Jun 2001 10:25:47 -0400

I think we are discussing 2 different issues on this thread:

1. A new fixed length L2TP header, with certain sequence numbering
paradigm. That MAY solve issues related DiffServ interaction 
with sequence numbering, and MAY (and I still do not understand how)
avoid need for multiple L2TP sessions for a PPP session.

2. Capability to split a PPP session into mutliple L2TP sessions for
current LAC which are capable of supporting packet classification.

Although, (1) maybe a better long term strategy, it touches not
just the issue of QoS. Can we split this thread in QoS and L2TP 
thread and L2TP Fixed header thread?

-Umesh

> -----Original Message-----
> From: W. Mark Townsley [mailto:[email-masked]]
> Sent: Wednesday, June 13, 2001 3:54 PM
> To: Jeff Mcadams
> Cc: Stewart Bryant; Wei Luo; Evan Caves; [email-masked]
> Subject: Re: Qos and L2TP (was: Do we want a new L2TP Header?)
> 
> 
> 
> 
> Jeff Mcadams wrote:
> > 
> > Also sprach Stewart Bryant
> > >With the IETF interest in adopting L2TP as the 
> encapsulation for PWE3,
> > >mandatory sequence numbers would present a problem. Some high speed
> > >routing architectures would find sequence numbers 
> difficult, and a lot
> > >of traffic does not need it.
> > 
> > >Of course if sequence numbers are present, they should 
> work, otherwise
> > >an additional sequence number field is needed as part of 
> the payload.
> > 
> > Well, we would certainly hang on to the sequencing required AVP for
> > protocols that require sequencing.  In changing the semantics of the
> > sequence number fields (ie, the LNS sending sequence 
> numbers no longer
> > requires the LAC to start using sequence numbers), we would 
> need to add
> > the ability to send that AVP in...say...the ICRP and OCRP?  Sound
> > reasonable?
> 
> That was my thought as well. Of course, this would just mean 
> that the sequence
> numbers are required to be present, not that you have to do 
> anything with them
> (which begs the question as to why in the world would you ask 
> for them if you
> didn't want to use them for something, but we can just leave 
> this up to simple
> logic).
> 
> > --
> > Jeff McAdams                            Email: [email-masked]
> > Head Network Administrator              Voice: (502) 966-3848
> > IgLou Internet Services                        (800) 436-4456
>

---

From: Jeff Mcadams <[email-masked]>
Date: Thu, 14 Jun 2001 10:53:15 -0400

Also sprach Umesh Sirsiwal
>I think we are discussing 2 different issues on this thread:

We did get a bit afield of the QoS issues...but it all connects back.

>paradigm. That MAY solve issues related DiffServ interaction with
>sequence numbering, and MAY (and I still do not understand how) avoid
>need for multiple L2TP sessions for a PPP session.

Well...the new sequence numbering paradigm allows the LAC and LNS to use
sequence numbering much less if the upper layer protocols allows for it.
If we can cut down on using sequence numbers as much as possible, then
that allows the inner IP header's DSCP to be propogated out to the outer
IP header's DS field without running into the performance issues that DS
re-ordering with sequence numbers enabled runs into.

Yes, if you are using sequence numbers, then you're still limited in
your ability to replicate the DS header to the outer header from the
inner header, but for packets that aren't using sequence numbers you can
change your outer header's DS field at will without danger of causing
even greater performance problems.  Its not a perfect solution (any
packets using sequence numbers still need to be part of one flow), but
its muh better.

>Although, (1) maybe a better long term strategy, it touches not just
>the issue of QoS.

Sure it does.  By enabling systems to use sequence numbers as little as
possible (which the new sequence number paradigm being discussed would
do), then you're allowing DS QoS to be used on the non-sequenced packets
without fear of more performance problems.  You can even include the
sequenced packets in the DS scheme as long as all of the sequenced
packets are treated with the same PHB along the way (the sequenced
packets all have to be in one flow).

>Can we split this thread in QoS and L2TP thread and
>L2TP Fixed header thread?

I think it would be worthwhile to have a seperate thread for
contemplating an L2TP fixed header, but the sequence number handling
really needs to stay with the QoS and L2TP thread as those two issues
are tied up together.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

---

From: Evan Caves <[email-masked]>
Date: Thu, 14 Jun 2001 09:57:25 -0700

With the proposed new sequencing paradigm I think the questions that
need to be asked is "What types of traffic need to be sequenced 
and have separate QOS attributes?" and "Can multiple streams of this 
traffic type exist within one PPP session?". If we can come up with 
some real world examples then there MAY be a need to split a single
PPP session into multiple L2TP sessions.

Certainly the typical environements are just IP over PPP over L2TP. 
In these cases the PPP control traffic SHOULD be sequenced and have a 
single DS mark. The IPCP packets need not be sequenced and the outer 
IP header can be DS marked accordingly.

evan
-

---

From: Jeff Mcadams <[email-masked]>
Date: Thu, 14 Jun 2001 13:01:26 -0400

Also sprach Evan Caves
>IP header can be DS marked accordingly.

IPCP is a PPP control protocol.  I think perhaps you meant "IP packets"
instead?
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

---

From: Evan Caves <[email-masked]>
Date: Thu, 14 Jun 2001 10:02:30 -0700

> IPCP is a PPP control protocol.  I think perhaps you meant "IP packets"

Yes I realized that right after I sent it. Duhhhhh

evan
-

---

From: Elwin Eliazer <[email-masked]>
Date: Mon, 18 Jun 2001 15:07:23 -0700 (PDT)

Hi Evan and others,

Sorry that i could not respond earlier on this.
From what i could gather from the recent emails
in this thread are:
   - sequence number in L2TP sessions are needed
     only for PPP control messages. And data
     packets MUST not turn on sequence numbers,
     especially when the tunnel is over a diffserv
     network.
   - there are mechanisms to achieve selectively
     enabling this sequencing only for PPP control
     messages (with existing L2TP standards)
   - when over a diffserv network, the PPP control
     messages are to be marked with a consistent
     DSCP, and sequencing are to be enabled.
   - LAC should not send SEQUENCING_REQUIRED AVP
     since that will ask for sequencing for the
     complete session.

If this is the case, then for QOS purposes, for
PPP over L2TP cases, a means to split a single
payload session into multiple L2TP sessions, may
not be required.

If there is anyone in the list who do not agree
to these, i would like to hear that.

Thanks.

cheers,
Elwin.

> IP header can be DS marked accordingly.

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

__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/

---

From: Jeff Mcadams <[email-masked]>
Date: Mon, 18 Jun 2001 18:46:19 -0400

Also sprach Elwin Eliazer
>     only for PPP control messages. 

No.  There are other protocols (bridged LAT was mentioned) that require
in order packet delivery (though not necessarily reliable packet
delivery)

>     And data

Eh...I'm not sure that would be a "MUST" there.  Turning no sequence
numbers when going through a diffserv network MAY result in worse
performance than is expected.  Potentially significantly worse.

>     messages (with existing L2TP standards)

Only from the LNS side.  Once the session is created, assuming the LAC
didn't use the sequencing required AVP, the LNS can selectively turn on
and off sequence numbers.  With existing L2TP standards, the LAC just
has to follow along with what the LNS does.

>If this is the case, then for QOS purposes, for PPP over L2TP cases, a
>means to split a single payload session into multiple L2TP sessions,
>may not be required.

Hrmm...I'm not sure that the current mechanisms for enabling and
disabling sequence numbers (only under LNS) control, are sufficient.  It
doesn't really provide for the granularity of using sequence numbers
only on packets that need to be delivered in-order as the LNS has no way
of knowing what packet is going to be coming next from the LAC, and
consequently whether it needs sequencing or not, additionally, there's
no way to ensure that the LNS can send packets at the right time to
enable and disable sequencing even if it did somehow magically know
whether the next packet the LAC was going to send would need sequencing.

>If there is anyone in the list who do not agree to these, i would like
>to hear that.

I've pointed out some flaws in the premises and arguments I believe.  :)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

---

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 18 Jun 2001 16:24:17 -0700

> whether the next packet the LAC was going to send would need sequencing.

Yes, when the dynamic sequencing was invented, the LAC being ignorant as
possible was of paramount concern. The LNS inherently "knows" whether sequencing
is necessary (or is at least best informed, assuming an LAC that does sniff
inner packets). I'm not sure that this was the best choice, as it has caused
packet sequencing support to be complicated enough that people tend to just
disable it. So, we learned that it is not always best to try to keep the side of
the tunnel with the L2 interface completely dumb. We will try and incorporate
this consensus as a proposal in the RFC2661 split l2tp base document.

---

From: Evan Caves <[email-masked]>
Date: Mon, 18 Jun 2001 16:51:24 -0700

> in order packet delivery (though not necessarily reliable packet

Sequence numbers are required for certain types of PPP traffic, PPP
control
traffic is one of them, CCP and MP are others.

> performance than is expected.  Potentially significantly worse.

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. 

> whether the next packet the LAC was going to send would need sequencing.

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).

evan
-

---

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 18 Jun 2001 16:50:45 -0700

Typo in last message.

> is necessary (or is at least best informed, assuming an LAC that does sniff
                                                                       ^not

---

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 18 Jun 2001 17:21:26 -0700

> like CCP or MP below IP then the LAC can't do squat anyways about

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.

> (and I suppose potentially bypassing out of sequence queued packets).

Yes, that sounds like the basic idea to me. 

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.

---

From: Jeff Mcadams <[email-masked]>
Date: Mon, 18 Jun 2001 20:45:36 -0400

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.

>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.

>> 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.  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!  :)

*heads off to the cvs tree*
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

---

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 18 Jun 2001 20:10:08 -0700

Jeff Mcadams wrote:
> 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

You wouldn't be the first.