Re: ppp draft issues - offset padding field

Hi Ignacio,

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

On 6/20/2007 3:39 PM, Ignacio Goyret said the following:
> 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.

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.

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

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

> 
> 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 protected]
> https://www1.ietf.org/mailman/listinfo/l2tpext
> 

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