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

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

Eliazer Elwin,

Good example, as you know, the l2tp sequence bits in data channel
is for detection only.

It is up to implementation to decide what to do with it.
You can chose drop the out of order packets or buffer them 
until everyone arrives.

Since your example choose to drop out of order packets,
it STILL happens if there are two separate l2tp sessions for p and q.

In this example, the DS domain does not guarantee deliver packet in order.
It even possible the packets with same DS value will not arrive in order
(e.g. some of them are dropped along the path due to congestion)
Even you have two separation l2tp sessions, the DS domain still does not
guarantee
packet delivery in order (due to packet drop or latency)

All you got is to help solving your choosing using sequencing number in l2tp
header
AND drop those out of order packets.

What's QoS is added for applications having p and q with two different
sessions?

Further more, it will be in sequence for application(a) using DS p and 
application(b) with DS q in this example.
However, since you choose to drop the "out of order" packets (in l2tp point
of view),
the application(b) using DS q suffering packets lost.

My analysis show you that you should ignore the l2tp sequence bits AND not
drop
a single packet at l2tp layer - faithfully deliver what was intent.

Unless l2tp "knows" every packets it carrys, l2tp can not
decide whether this is what the traffic originator's intent.

Solution produces problem is irrational.

--- David

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

Chen David,

Take for example 4 packets, A, B, C, D.
And 2 QOS values: p, q

When there is one L2TP session,
when the LAC sends packets: Ap1, Bq2, Cp3, Dq4
  where the last digit is sequence number,
the LNS receives it as: Ap1, Cp3, Bq2, Dq4
since the intermediate DS domain reorders and
gives more priority to traffic type 'p'.
LNS when it processes these packets from a session
will drop Bq2 since it has come out of order.

THIS WILL NOT HAPPEN WHEN THERE ARE TWO SEPARATE
L2TP SESSIONS FOR 'p' and 'q'.

regards,
Elwin.

--- Umesh Sirsiwal <[email-masked]>
wrote:
> > This is exactly what I like to know how this can
> happen since the l2tp
> > session
> > 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
> 

=====
-------
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: Ignacio Goyret <[email-masked]>
Date: Tue, 05 Jun 2001 09:19:11 -0700

Two points:
a) the intention of l2tp sequence numbers are to allow reordering of packets
   at the arriving tunnel endpoint. (RFC2661, section 3.0, second to last paragraph).
b) l2tp sequence numbers _can_ be disabled and re-enabled at run time.
   In fact, rfc2661 section 5.4 makes this very clear:

   "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.
   If this AVP is not present, sequencing presence is under control of the LNS.
   The LNS controls enabling and disabling of sequence numbers by sending a
   data message with or without sequence numbers present at any time during
   the life of a session."

So, my suggestion would be that once the LNS figures it out that the session
will transport DS-sensitive data, well just stop using sequence numbers. That
will prevent L2TP from reordering packets that were reordered by their different
DS settings and it avoids the significant complication of multiple L2TP sessions
for a single PPP session.

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 5 Jun 2001 13:03:07 -0400

Also sprach Ignacio Goyret
>Two points:
>a) the intention of l2tp sequence numbers are to allow reordering of
>   packets at the arriving tunnel endpoint. (RFC2661, section 3.0, second
>   to last paragraph).

>   "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.  If this AVP is not present, sequencing
>   presence is under control of the LNS.  The LNS controls enabling and
>   disabling of sequence numbers by sending a data message with or
>   without sequence numbers present at any time during the life of a
>   session."

>So, my suggestion would be that once the LNS figures it out that the
>session will transport DS-sensitive data, well just stop using sequence
>numbers. That will prevent L2TP from reordering packets that were
>reordered by their different DS settings and it avoids the significant
>complication of multiple L2TP sessions for a single PPP session.

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

---

From: Ignacio Goyret <[email-masked]>
Date: Tue, 05 Jun 2001 09:43:43 -0700

At 01:03 PM 6/5/01 -0400, Jeff Mcadams wrote:
>>   present at all times.

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.

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 5 Jun 2001 13:20:07 -0400

>are found out there and the latter requires LACs and LNSs that don't

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