Re: [tsvwg] Benoit Claise's No Objection on draft-ietf-tsvwg-sctp-prpolicies-06: (with COMMENT)

[Benoit Claise <[e-mail]>]

On 03/02/2015 18:57, Brian Trammell wrote:
> hi Benoit, all,
>
> I can perhaps shed a light on this point, inline below:
>
>> On 03 Feb 2015, at 18:25, Michael Tuexen <[e-mail]> wrote:
>>
>>> On 03 Feb 2015, at 18:05, Benoit Claise <[e-mail]> wrote:
>>>
>>> Benoit Claise has entered the following ballot position for
>>> draft-ietf-tsvwg-sctp-prpolicies-06: No Objection
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>> Hi Benoit,
>>
>> thanks a lot for the review. See my comments in-line.
>>
>> Best regards
>> Michael
>>> 1.
>>>   Using the Priority Policy allows the sender of a user message to
>>>   specify a priority.  When storing a user message in the send buffer
>>>   while there is not enough available space, the SCTP stack at the
>>>   sender side MAY abandon other user messages of the same SCTP
>>>   association with a priority lower than the provided one.
>>>
>>>>  From the same SCTP association or the same stream within the SCTP
>>> association? Or is this implementation specific?
>> As specified above: It is only from the same association. Normally the
>> buffering is done per socket.
>>> 2.
>>> While reading through the draft, I was actually wondering how I could use
>>> those extensions in IPFIX.
>>> The first one is not applicable. Then I found in section 3.2:
>>>
>>> The Priority Policy can be used in the IPFIX protocol stack.  See
>>>   [RFC7011] for more information.
>>>
>>> This is a little lit light. I believe you should explain the use case you
>>> have in mind... because I don't believe this was an IPFIX requirement.
>> I'm not sure. What I remember is that IPFIX has messages of different
>> priorities and that you wanted to be able to drop lower priority messages
>> for higher ones. That is why the policy got implemented. If the
>> applicability is no longer true, I can remove the above sentence.
>> Looking at
>> https://tools.ietf.org/html/rfc7011
>> shows multiple references to RFC 3758, but is not clear either.
> This probably comes from a some hallway discussions Michael and I had during the completion of RFC 5101 in 2008; we were looking at how the single then-implemented timeout-based PR-SCTP policy mapped to what we thought the IPFIX requirements were for partial reliability. It didn't, really, but it was what we had.
>
> We briefly discussed counting retransmissions as well (as in section 3.1) but this also had the problem that an IPFIX exporting process would have just as much information about network conditions to set a retransmission count as it would a timer (i.e. none) to get the tradeoff it was looking for between retransmission load and loss.
>
> What the EP *does* know is which message is more important than which other message, hence 3.2.
>
> None of this made it into the final language in 5101 (or subsequently 7011) because we decided explicitly not to provide detailed guidance on SCTP usage in the core protocol, instead pointing out the per-stream optimization as optional (RFC 6526) but letting implementation experience guide further usage.
>
> None of this makes it clear from looking at the *documents* why all of this makes sense,
Exactly. I struggled exactly on that point.
I believe this explanation is required.
> but we could add a sentence explaining this to the prpolicies draft.
Either how it could be used in IPFIX today or a different example.

Regards, Benoit
>
> Cheers,
>
> Brian
>
>
>> Best regards
>> Michael
> .
>