Subject: [L2tpext] ppp draft issues - offset padding field

From: Ignacio Goyret <[email-masked]>
Date: Wed, 20 Jun 2007 12:39:38 -0700

Hi all,
On the PPP draft for L2TPv3, there is an optional offset
padding field that can be requested by the receiver to be
inserted by the sender. As the draft is currently written,
this insertion is not negotiable: if the receiver asks for
it, the sender MUST insert it, even if doing so would be at
a performance cost. This is unacceptably unfair, as it shifts
the problems of a poor receiver design to the sender.

In my opinion, the offset padding field is (and has always been)
unnecessary since we are transporting PPP packets. If the receiver
needs to have an specific alignment, it is very likely that it
will need to move the packet at some point or another to deal
with things like ACFC, PFC, compression, MP headers, etc.

I would like to propose one of the following two alternatives:

1) eliminate the offset padding field altogether.
   This is my preferred choice.

2) if we decide to keep the offset padding field, it should be
   somehow negotiated with the sender side.

If option #2 was preferred, the negotiation could be done the
same way that it is done in RFC3573: each side tells the other
how far they are willing to go.

A new AVP would be sent on the ICRQ/ICRP/OCRQ/OCRP to indicate
the willingness of the message sender's side to insert an offset
and how long that offset might be. If the AVP is not included,
it means the message sender will not insert any offset (regardless
of any received Offset Size AVP).

The received value of this new AVP, together with the sent Offset
Size AVP will tell the receiver what to expect in terms of the
offset padding field: if the sender said it is willing to insert
up to 4 bytes and the receiver asked (or was going to ask) for 6,
only 4 bytes will be inserted by the sender. If the sender said up
to 8 bytes and the receiver asked for 6, the sender will insert
6 bytes. If the sender said no offset will be inserted, nothing
will be inserted.

Again, my preference is #1 as that would eliminate a significant
protocol complexity that adds no benefit (IMHO).

Opinions, please?

-Ignacio

PS: This draft expired recently but a new one is in the works.
In the meantime, you can look here for the last version:
http://tools.ietf.org/html/draft-ietf-l2tpext-l2tp-ppp-05

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: Carlos Pignataro <[email-masked]>
Date: Tue, 26 Jun 2007 16:33:33 -0400

Hi Ignacio,

Thank you for sending this. Please find my comments inline.

> the problems of a poor receiver design to the sender.

Please note that the motivation was to continue with the L2TPv3-base
downstream-control of other dataplane characteristics such as the L2SS
presence and value, Session ID, Cookie size and value, etc.
I agree that the current text can be improved though, see below.

> of any received Offset Size AVP).

Rather than a session-level negotiation, how about a tunnel-level
SCCRQ/SCCRP capability advertisement, much like the "Pseudowire
Capabilities List" or the "Modem On-Hold Capable AVP" from Section 4.1
of RFC3573. A "Offset Capability" AVP can indicate how big of an offset
the sender is willing to insert, if requested at session-level.

The "Offset Capability" AVP can have the same syntax as the "Offset
Size" with different semantics. It could even be the same AVP number
(with semantics depending on the type of message in which the AVP is
in), or (my preference) a new AVP.

That would allow the sender to have control via capability, and would
default to #1 if the "Offset Capability" is missing or it has a zero
value. Would that be an acceptable solution?

Thanks,

--Carlos (as editor).

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

---

From: Ignacio Goyret <[email-masked]>
Date: Tue, 26 Jun 2007 13:47:15 -0700

>the sender is willing to insert, if requested at session-level.

Sure, session-level or tunnel-level is fine by me.

I would still like to make this feature disappear though and go
for the simpler solution of just removing something that has
questionable value.

>It could even be the same AVP number

I think it will be better if it is a new AVP.
It is cleaner and it makes parsing and displaying much easier.
I don't think there is any AVP that has more than personality and
I think it is better to keep it that way.

Cheers,
-Ignacio

---

From: Carlos Pignataro <[email-masked]>
Date: Tue, 26 Jun 2007 17:04:35 -0400

> I think it will be better if it is a new AVP.

Yes, I agree.

> I think it is better to keep it that way.

There is one, from RFC3931:

      The Control Connection Tie Breaker AVP, Attribute Type 5,
...
      Note that in [RFC2661], this AVP is referred to as the "Tie
      Breaker AVP" and is applicable only to a control connection.  In
      L2TPv3, the AVP serves the same purpose of tie breaking, but is
      applicable to a control connection or a session.  The Control
      Connection Tie Breaker AVP (present only in Control Connection
      messages) and Session Tie Breaker AVP (present only in Session
      messages), are described separately in this document, but share
      the same Attribute type of 5.
...
      The Session Tie Breaker AVP, Attribute Type 5, is used to break

But I agree that having separate AVPs is cleaner. Also, I think the
potential flexibility in leaving it is the safer path, and setting the
"Offset Capability" to zero effectively makes this feature disappear if
desired by an implementation.

Thanks,

--Carlos (as editor).

---

From: "Y Prasad" <[email-masked]>
Date: Wed, 27 Jun 2007 13:55:39 +0530

Hi Carlos,

Please see at <yp>

<yp> In v3 case tunnel can potentially carry non-ppp sessions. Do you
think offset size useful/needed across all non-ppp sessions as well?
Common offset size for all the different types of sessions may not
benefit all the sessions.

May be we are better off to keep it as session negotiated AVP?

May be we can have this rule?

- If receiver of this AVP decides to support this feature he should ack
the same so that sender knows for sure he can expect alignment that he
needs.
- Else sending this AVP is a nop to sender/receiver.

My $.02 :), of course.

Regards
yp

Thanks,

--Carlos (as editor).

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 27 Jun 2007 17:02:04 -0400

Thank you for the comments, please see inline.

> think offset size useful/needed across all non-ppp sessions as well?

This is a good point. Even though v3 supports other PW Types, the Offset
Size is only applicable to PPP sessions. Other companion documents
(i.e., other PW Types) do not specify it, and the PPP document specifies
other AVPs that are also only applicable to PPP.

> benefit all the sessions.

Note that there's not necessarily a common offset size for all PPP
sessions. The Offset Size is a Session Management AVP (per-session).
More below.

> May be we are better off to keep it as session negotiated AVP?

The "OFfset Size" is a Session-requested AVP. The "Offset Capability"
only conditions/caps the maximum Offset Size that can be requested on
sessions belonging to a given tunnel.

> the same so that sender knows for sure he can expect alignment that he

Note also that both directions could request a different offset size,
much like requesting (or not) and L2SS, or requesting (or not) different
Cookie size (and value).

> - Else sending this AVP is a nop to sender/receiver.

I think that per-tunnel capability and per-session request is simpler,
and (more importantly) aligned with how other AVPs/capabilities are
currently signaled: Tunnel-level capabilities (from example from RFC3573
that Ignacio cited, and all the "xxx Capabilities" AVPs) and at the
session-level, the downstream (receiver, decap) requests what he wants
sent to it (L2SS, Cookie, Session ID, etc).

> My $.02 :), of course.

Much appreciated. What do you think?

Thanks,

--Carlos.

---

From: "Y Prasad" <[email-masked]>
Date: Thu, 28 Jun 2007 05:01:01 +0530

Thanks Carlos for explaining difference between offset size and offset
capability. Please see a comment below.

-----Original Message-----
From: Carlos Pignataro [mailto:[email-masked]] 
Sent: Thursday, June 28, 2007 2:32 AM
To: Y Prasad
Cc: Ignacio Goyret; [email-masked]
Subject: Re: [L2tpext] ppp draft issues - offset padding field

<yp> wondering what will be the behavior in the following case:
session may get initiated/configured long after the tunnel is up. So if
a ppp session that requires offset and the tunnel had not negotiated
offset capability, then we will bring down tunnel to negotiate offset
capability?

(IMHO)why not we just mention offset size avp as "ackable" session AVP
and avoid offset capability need. I think its ok to define a new avp
type behavior.

Regards
yp

Thanks,

--Carlos.

---

From: Carlos Pignataro <[email-masked]>
Date: Thu, 28 Jun 2007 09:51:42 -0400

> offset capability, then we will bring down tunnel to negotiate offset

If the offset capability is supported, it needs to advertise it at
tunnel creation (SCCRQ, SCCRP). This is true for all capabilities;

> and avoid offset capability need. I think its ok to define a new avp

This is in a way what the current text describes, with the "nak"
(meaning "I won't add that offset size") being a CDN. Ignacio argued
that control over the offset would need be placed in the device that
would add the offset, and that's what the capability solves.

There is an additional problem with session-management negotiation of
this: In the outgoing call establishment negotiation, the first message
where a LAC can say "you can request up to this" is with the OCRP, but
the LNS has only a chance to request a specific offset size in the OCRQ,
which happens before. I think that the tunnel-level advertisement solves
the problem presented by Ignacio in all cases, and is simpler.

Thoughts?

Thanks,

--Carlos.