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

From: "Chen, David" <[email-masked]>
Date: Mon, 11 Jun 2001 11:26:41 -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?)

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 

> -----Original Message-----
> From:	Chen, David [SMTP:[email-masked]]
> Sent:	Monday, June 04, 2001 6:23 PM
> To:	[email-masked]'; Chen, David
> Cc:	[email-masked]
> Subject:	RE: Qos and L2TP (was: Do we want a new L2TP Header?)
> 
> 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?)
> 
> 
> > 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:
> 
> 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
> 
> ---------------------------------------------------
> 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
> ---------------------------------------------------
> 
> > -----Original Message-----
> > From:	Chen, David [SMTP:[email-masked]]
> > Sent:	Monday, June 04, 2001 10:22 AM
> > To:	[email-masked]'; Chen, David
> > Cc:	[email-masked]
> > Subject:	RE: Qos and L2TP (was: Do we want a new L2TP Header?)
> > 
> > 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?)
> > 
> > 
> > > 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.
> > 
> > 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: Elwin Eliazer <[email-masked]>
Date: Tue, 12 Jun 2001 10:24:38 -0700 (PDT)

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.

=====
-------
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: Evan Caves <[email-masked]>
Date: Tue, 12 Jun 2001 14:46:23 -0700

I personally do not like the idea of splitting a single PPP session
into multiple L2TP sessions to provide separate QOS's. This really
seems like a bad idea.
Correct me if I am wrong but the reasons I thought we needed payload
sequencing were for the following reasons:

1. to ensure LCP and NCP packets were processed by the PPP state 
   machine in order (and drop out of sequence frames).
2. if CCP was negotiated.
3. if multilink was negotiated(?)

I think it is clear that one cannot create multiple l2tp sessions
and a base l2tp session out of items (2) and (3). For item (1) the
LAC and LNS need to ensure that whenever a PPP control frame is
sent that sequence numbers are turned on for those frames. All other
frames can have sequence numbers turned off. This would allow the
LAC and LNS to, under whatever policy that controls them, to use
different DSCP's for all traffic within a single L2TP session.

evan
-

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 12 Jun 2001 18:30:14 -0500

> different DSCP's for all traffic within a single L2TP session.

I don't want to weigh in on the diffserv discussion at the moment. However,
Evan, you bring up an interesting point with regard to sequence number that has
been on my mind lately. 

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: Evan Caves <[email-masked]>
Date: Tue, 12 Jun 2001 16:02:32 -0700

Works for me. Sequence number space would have to be 1-65535 (zero 
meaning no seqence number present.

evan
-

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 12 Jun 2001 19:19:29 -0400

Also sprach W. Mark Townsley
>> into multiple L2TP sessions to provide separate QOS's. This really

FWIW, I'm not a big fan of it either...but I don't know that I can come
up with a better idea.

>> 3. if multilink was negotiated(?)

I was under the impression that there were other (non-IP) upper layer
protocols that cannot tolerate re-ordering, and that the sequence
numbers were there to support them.  I'm an IP geek through and through,
so don't have any experience with any protocol that would fit this
description, but that's been my understanding.

>> I think it is clear that one cannot create multiple l2tp sessions and
>> a base l2tp session out of items (2) and (3). For item (1) the LAC
>> and LNS need to ensure that whenever a PPP control frame is sent that
>> sequence numbers are turned on for those frames. All other frames can
>> have sequence numbers turned off. This would allow the LAC and LNS
>> to, under whatever policy that controls them, to use different DSCP's
>> for all traffic within a single L2TP session.

Well, for at least most of it.  Unless I'm mis-thinking this, it would
let you have as many DSCP's as you wanted for the "non-sequenced"
traffic, plus one DSCP for the "sequenced" traffic.

>I don't want to weigh in on the diffserv discussion at the moment.
>However, Evan, you bring up an interesting point with regard to
>sequence number that has been on my mind lately. 

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

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

The biggest ugliness I see in this proposal (and this is relatively
minor) is that when sequence counters roll over (not an infrequent
occurance), 0 is currently a valid sequence number to use.  Not a huge
deal, but it does require a bit of special case processing in sequence
number handling in code because of it.

I would almost rather see a flag bit in the header indicating whether to
use the sequence number in the header.  We already have a flag bit
indicating whether the sequence number fields are in the
header...perhaps we should redefine this to this semantic and require
that the sequence number field always be present (though potentially
ignored)

I guess whether the sequence fields are present in the header is a
seperate issue...you could just as easily say use the sequence numbers
if the S bit is set, and don't use them if the S bit isn't set and
therefore aren't present.

I hope this isn't re-opening old wounds from L2TP's draft days...I
wasn't around for any of those discussions, so don't know what thoughts
and discussions went into this, but in working with l2tpd, I've found
that the variable nature of the L2TP header is a bit of a complication,
so I tend to favor fixed formats for headers.  *shrug*  The variability
of L2TP's header format isn't all that big of a deal...the code to deal
with it isn't terribly complex, but it is just one more complication for
a dubious benefit.

So...if I had my say...redefine the S bit to indicate whether to pay attention
to or ignore the sequence number fields which would always be present.
If the sequence number fields are ignored, then that gives you free
reign to play with you DSCPs all you want, the only restriction at that
point would be that you only want to have a single DSCP for L2TP frames
with the S bit set...still a bit restrictive, but a dern sight better in
my opinion than multiple L2TP sessions, or fragmenting the sequence
number space.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

---

From: Wei Luo <[email-masked]>
Date: Tue, 12 Jun 2001 16:32:58 -0700

These ideas are probably more useful than the current RFC2661 sequence 
number scheme.  Having a fixed header and always-present sequence number 
field seems the right way to go.  BTW, someone raised an issue stating 
32-bit sequence number not enough for very high speed links, e.g. OC-192, 
on the PWE3 mailing list.  Maybe the new L2TP header wants to adopt a 
longer sequence number field?

---Wei

At 04:02 PM 6/12/2001 -0700, Evan Caves wrote:
> ability
> they are
> relative to
> sequence

---

From: Evan Caves <[email-masked]>
Date: Tue, 12 Jun 2001 16:41:06 -0700

> description, but that's been my understanding.

Bridging LAT for example :-)

> traffic, plus one DSCP for the "sequenced" traffic.

Yup.

> my opinion than multiple L2TP sessions, or fragmenting the sequence

Ahhh yes. This is much better than special casing sequence number zero (
although this would not be the first time ala OSPF)

evan
-

---

From: Evan Caves <[email-masked]>
Date: Tue, 12 Jun 2001 16:45:59 -0700

[snip...]

> my opinion than multiple L2TP sessions, or fragmenting the sequence

Just to clarify. Using either sequence number zero or the S-bit require
LAC and LNS to agree on this new interpretation (new AVP, protocol rev) 
so I also would prefer the s-bit approach.

evan
-

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 12 Jun 2001 20:08:51 -0500

> so I also would prefer the s-bit approach.

Actually, I think there would need to be a new AVP in either case. As for a
protocol rev, this is probably a separate decision with various features such as
this as input. e.g. any one small change probably could be represented in an AVP
alone, while a "collection" of changes might do well to be identified together
as a revision on the protocol.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 12 Jun 2001 20:22:33 -0500

> with it isn't terribly complex, but it is just one more complication for

Yeah, IP has those pesky options in its header too. Fragmentation isn't a real
hit at high speeds either. Oh well.

One of the prevailing concerns of the day was header size, thus we have variable
fields much like GRE does. Which, no surprise, was part of the input into L2TP
(well, really L2F and PPTP which, in turn, was input into L2TP). 5 years later,
we would probably do well to have an aligned, fixed header with less attention
to the size. This would be easy enough to signal upfront, much the way we do for
l2tphc. Wonder what kind of header we will want 5 years from now? 

- Mark

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 12 Jun 2001 23:37:56 -0400

>Yeah, IP has those pesky options in its header too. Fragmentation isn't
>a real hit at high speeds either. Oh well.

Wups...looks like I did re-open old wounds...I was afraid of that.

IP options I would compare more to AVPs...most likely parsed serially
after you've finished mucking around with the bulk of the fixed header.
You're not trying to find a specific field in the midst of them such as
you are likely to see code doing with trying to find sequence numbers in
the midst of an L2TP header...do I start looking at byte 65, or 49?
Like I said...its not a big deal, but it does add some complexity to
code.

I'm not sure the argument about fragmentation is too terribly
significant.  While saving 48 bytes isn't *in*significant, how often is
it going to save you from having to deal with fragmentation?  Looking at
packet size distributions that I've seen, its not going to be *all* that
often.  If you have to fragment with the extra fields in there, you're
likely to have to fragment regardless.  I do understand the concern...I
just don't know that the solution (short of l2tphc) really helped.

>One of the prevailing concerns of the day was header size, thus we have
>variable fields much like GRE does. Which, no surprise, was part of the
>input into L2TP (well, really L2F and PPTP which, in turn, was input
>into L2TP).

I'll certainly give a tip of the hat to historical considerations...and
I certainly don't want to come off like I'm blaming people for the
variableness of the L2TP header.

>5 years later, we would probably do well to have an aligned, fixed
>header with less attention to the size. This would be easy enough to
>signal upfront, much the way we do for l2tphc.

Indeed...I certainly wouldn't want to capriciously change this...but if
the header is gonna get changed anyway, which it sounds like what we're
leading to with the DS discussion, then it would also be a possibility
to bring some other things up to how we would like to see them handled
today.

>Wonder what kind of header we will want 5 years from now? 

Good question...definitely one that would be worthwhile
considering...perhaps we can avoid a similar discussion as this in the
future if we tackle that discussion.  Things that I can think of that it
seems likely that we would regret would be just about anything not
byte-aligned in the main part of the header, which pretty much means the
flags and the Version field.  I can conceive of someone 5 years from now
asking if it was worth it to have 4 extra reserved flags instead of just
using an 8 bit version field?  Or maybe just have 16 bits of flags and
16 bits of version?  Something along those lines possibly.  I can't say
that I've been in this field long enough (I'll readily admit to being
rather new at all of this compared to others that participate here) to
be able to reasonably predict any of this.  Am I advocating changing the
flags and version field?  No way...at least not at this point.  I'll let
others more knowledgeable than I comment first.  :)  I'm sure there are
probably other things that I'm missing as well on this point.
-- 
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: Wed, 13 Jun 2001 00:26:09 -0500

> just don't know that the solution (short of l2tphc) really helped.

The issue wasn't just popping over the MTU. In fact, the same argument you give
here was given on the list if memory serves. L2TP was targeted at the PPTP
market as well, which saw its header pass over slow dialup links where every
byte tended to count. IMO we should have had the "standard" header and the
"compressed" header and no more. You know what they say about hindsight...

> to bring some other things up to how we would like to see them handled

Yes, the proverbial can of worms. If this WG can tame the worms and come up with
something obviously better (the latter is the easy part), and people actually
change their code to match it so we don't end up supporting *both* everywhere
(by far the most difficult part), then we will have done a good deed.

> probably other things that I'm missing as well on this point.

Fresh eyes can be a good thing at times (often depending on the eyes!).

Actually, we could change the flags and version as long as we secure a new UDP
port or IP protocol to operate over. If we are doing surgery anyway, we might as
well consider all possibilities.

---

From: Jeff Mcadams <[email-masked]>
Date: Wed, 13 Jun 2001 08:43:43 -0400

>> significant.  While saving 48 bytes isn't *in*significant, how often
>> is it going to save you from having to deal with fragmentation?
>> Looking at packet size distributions that I've seen, its not going to
>> be *all* that often.  If you have to fragment with the extra fields
>> in there, you're likely to have to fragment regardless.  I do
>> understand the concern...I just don't know that the solution (short
>> of l2tphc) really helped.

>The issue wasn't just popping over the MTU. In fact, the same argument
>you give here was given on the list if memory serves. L2TP was targeted
>at the PPTP market as well, which saw its header pass over slow dialup
>links where every byte tended to count. IMO we should have had the
>"standard" header and the "compressed" header and no more. You know
>what they say about hindsight...

Heh...right...and I think we could easily get to that, with l2tphc in
the works (which I must confess to having only skimmed the draft for
that), we might end up with a standard and a compressed header down the
road.

>> Indeed...I certainly wouldn't want to capriciously change this...but
>> if the header is gonna get changed anyway, which it sounds like what
>> we're leading to with the DS discussion, then it would also be a
>> possibility to bring some other things up to how we would like to see
>> them handled today.

>Yes, the proverbial can of worms. If this WG can tame the worms and
>come up with something obviously better (the latter is the easy part),
>and people actually change their code to match it so we don't end up
>supporting *both* everywhere (by far the most difficult part), then we
>will have done a good deed.

Indeed...and those are some pretty big "ifs" there.  This is all a bit
of blue sky thinking I guess.  For the DS discussion though, it looks
like a change to the sequence number fields and/or S bit is going to be
necessary, so this would be a good time to get at least this part right.
Going on and changing other parts of the header may be a bit much to
tackle at this point...unless we do take this, and l2tphc, and maybe
some of the other drafts and roll them into a new version of L2TP as you
mentioned.  The more I think about it, the more that idea begins to
appeal to me.  That's really a major project though and probably not
something we really even need to consider at the moment...let these
proposals live on a drafts and move down the track that they're on and
down the road we can roll them all together into a new L2TP version if
we like.  *shrug*

>Actually, we could change the flags and version as long as we secure a
>new UDP port or IP protocol to operate over. If we are doing surgery
>anyway, we might as well consider all possibilities.

Oi...new port numbers...hrmm...then we'd basically be defining a wholely
new protocol and might as well just start from scratch.  Hrmm...I think
maybe leaving the flags and version field untouched is a good idea.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 13 Jun 2001 14:07:23 +0100

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.

Stewart

---

From: Jeff Mcadams <[email-masked]>
Date: Wed, 13 Jun 2001 09:18:19 -0400

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. 

>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?
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

---

From: Wei Luo <[email-masked]>
Date: Wed, 13 Jun 2001 10:18:00 -0700

I think the ADs were pretty clear about the direction of defining 
requirements in the PWE3 interim meeting, which is that you cannot say some 
chips or hardware platforms cannot do such and such, then you rule out 
certain things in a protocol.  There are always special cases, and it's 
impractical for a standard body to take everything into account.

---Wei

At 02:07 PM 6/13/2001 +0100, Stewart Bryant wrote:

> However,

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 13 Jun 2001 14:52:15 -0500

> difficult, and a lot of traffic does not need it.

As was discussed at the PWE3 interim meeting in Denver, we MUST provide a
*definition* for how to preserve, or at least detect, packet order. Whether the
operator chooses to enable this is another issue entirely.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 13 Jun 2001 14:54:17 -0500

> the ability to send that AVP in...say...the ICRP and OCRP?  Sound

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