RE: ppp draft issues - offset padding field

Please see in-line response at <yp>

> -----Original Message-----
> From: Carlos Pignataro [mailto:[email protected]]
> Sent: Friday, July 06, 2007 8:28 PM
> To: Y Prasad
> Cc: Ignacio Goyret; [email protected]
> Subject: Re: [L2tpext] ppp draft issues - offset padding field
> 
> 
> 
> On 7/5/2007 12:32 PM, Y Prasad said the following:
> > Agree with you Carlos.
> >
> > If capability advertise mentions max size offset support, then each
> > session can just request offset size without any response
expectation to
> > the avp ?
> > Meaning offset size avp can be request-only-no-response-needed one?
> > If the received size is invalid due to implementation issues of the
> > peer, CDN may be sent to the requesting peer.
> 
> Yes, exactly.


<yp> Thanks, Carlos for the confirmation.

> 
> >
> > Offset size avp can be valid for non-ppp type sessions? If so we may
> > define this as generic avp?
> 
> That would be outside the scope of this document, which covers only
ppp.
> RFC3931 or other companion documents have not defined any offset, so
> it's ppp-only.
<yp>
IMHO:
Offset feature is useful for non-ppp type of session as well. So it is
worth to define this avp as part of generic rather than every protocol
ending up in defining in their respective drafts. I know this is out of
scope of current ppp draft/discussion. But still it is under the scope
of "l2tpext" working group?

With best regards
yp

> 
> Thanks,
> 
> --Carlos.
> 
> >
> > Regards
> > yp
> >
> >
> >> -----Original Message-----
> >> From: Carlos Pignataro [mailto:[email protected]]
> >> Sent: Wednesday, July 04, 2007 1:37 AM
> >> To: Y Prasad
> >> Cc: Ignacio Goyret; [email protected]
> >> Subject: Re: [L2tpext] ppp draft issues - offset padding field
> >>
> >> Thanks again, please see inline.
> >>
> >> On 7/3/2007 3:42 PM, Y Prasad said the following:
> >>> Hi Carlos,
> >>>
> >>>> -----Original Message-----
> >>>> From: Carlos Pignataro [mailto:[email protected]]
> >>>> Sent: Thursday, June 28, 2007 7:22 PM
> >>>> To: Y Prasad
> >>>> Cc: Ignacio Goyret; [email protected]
> >>>> Subject: Re: [L2tpext] ppp draft issues - offset padding field
> >>>>
> >>>>
> >>>>
> >>>> On 6/27/2007 7:31 PM, Y Prasad said the following:
> >>>>> Thanks Carlos for explaining difference between offset size and
> >>> offset
> >>>>> capability. Please see a comment below.
> >>>>>
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Carlos Pignataro [mailto:[email protected]]
> >>>>> Sent: Thursday, June 28, 2007 2:32 AM
> >>>>> To: Y Prasad
> >>>>> Cc: Ignacio Goyret; [email protected]
> >>>>> Subject: Re: [L2tpext] ppp draft issues - offset padding field
> >>>>>
> >>>>>
> >>>>> Thank you for the comments, please see inline.
> >>>>>
> >>>>> On 6/27/2007 4:25 AM, Y Prasad said the following:
> >>>>>> Hi Carlos,
> >>>>>>
> >>>>>> Please see at <yp>
> >>>>>>
> >>>>>> 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.
> >>>>>>
> >>>>>> <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?
> >>>>> 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.
> >>>>>
> >>>>>> Common offset size for all the different types of sessions may
> > not
> >>>>>> 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.
> >>>>>
> >>>>> <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?
> >>>> If the offset capability is supported, it needs to advertise it
at
> >>>> tunnel creation (SCCRQ, SCCRP). This is true for all
capabilities;
> >>> <yp>
> >>> Not sure whether we still need to advertise particular session
type
> >>> capabilities (here ppp specific) over the tunnel when the same is
> > again
> >>> negotiated over session. We may have some thing like below
> >> Yes, it would be one or the other. The purpose of the capability
> >> advertisement in SCCRQ/SCCRP is, as you describe below, to not have
to
> >> negotiate at the session level, and maintain the same signaling
flow
> > as
> >> as with other messages, in which the receiving side requests some
> >> dataplane characteristic.
> >>
> >> More importantly, see below re. outgoing calls.
> >>
> >>>  Lac  ---------- lns
> >>> ICRQ   ----------> (lac advertise offset capability)
> >>> ICRP   <----------- (lns request offset size and advertise its
> >>> capability)
> >>> ICCN   -----------> lac request offset size
> >>>
> >>> I am ok for advertising thru SCCRQ/SCCRP though as it helps each
> > session
> >>> not to try for offset negotiation when peer does not support.
> >> OK.
> >> And agreed as another reason.
> >>
> >>>>> (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.
> >>>> 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.
> >>> <yp>
> >>> Since this addresses only performance issue, un-supported
situations
> > may
> >>> not need to end up in disconnecting the session when peer
> > negotiates.
> >>> IMHO, offset padding avp can be a simple ackable non-mandatory avp
> > that
> >>> can be requested by either of the peers independently.
> >>>
> >>>> 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.
> >>> May be this way?
> >>>
> >>>    LAC  ---- LNS
> >>>
> >>>        <----- OCRQ (lns advertise offset capability)
> >>>
> >>>   OCRP  ------> (lac request offset padding and advertise its
> > capability
> >>> as well)
> >>>
> >>>   OCCN  <-------- (lns reqest offset padding)
> >> The problem here is that the OCCN is in the other direction:
> >>     OCCN  ------>
> >>
> >> So if the LAC advertises its capability in the OCRP, the LNS cannot
> >> request the offset padding.
> >>
> >> http://tools.ietf.org/html/rfc3931#section-3.4.2
> >> http://tools.ietf.org/html/rfc2661#section-5.2.2
> >>
> >> Based on this discussion and your comment above, I'm inclined to
> > update
> >> with an SCCRQ/P capability advertisement. That seems inline with
> >> existing flow, and solves the requirement. Would that work?
> >>
> >> Regards,
> >>
> >> --Carlos (as editor).
> >>
> >>> Regards
> >>> yp
> >>>> Thoughts?
> >>>>
> >>>> Thanks,
> >>>>
> >>>> --Carlos.
> >>>>
> >>>>
> >>>>> Regards
> >>>>> yp
> >>>>>
> >>>>>> 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.
> >>>>> 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.
> >>>>>
> >>>>>> Regards
> >>>>>> yp
> >>>>>>
> >>>>>>
> >>>>>> 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
> >> --
> >> --Carlos Pignataro.
> >> Escalation RTP - cisco Systems
> >
> 
> --
> --Carlos Pignataro.
> Escalation RTP - cisco Systems