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

[Benoit Claise <[e-mail]>]

Michael, Brian,

I like your two combined proposals.

Thanks and regards, Benoit
> hi Michael,
>
> This is good, though I'd tweak it slightly...
>
>>> In case of IPFIX, you want to have different flow records per stream, and you want to flag those streams as fully reliable/partially reliable/unreliable (I know it's not totally correct, as the reliability is flagged per message, as opposed to streams, in SCTP, but anyway)
>>> Typically, you want a billing flow-record sent fully reliably, security-related and monitoring flow-records sent partially-reliably. Now, if you consider the security-related slightly more important than the monitoring ones, the exporting process might flag the security-related flow records with a higher priority than the monitoring ones, according to this spec.
>>>
>>> You might have to introduce an example around this text above.
>> What about writing:
>>
>> <t>The IPFIX protocol stack (see <xref target='RFC7011'/>) is an example
>> of where the Priority Policy can be used. Billing flow-records would be sent
> ... Template records would be sent with full reliability, while billing, security-related, and other monitoring flow records would be sent using the Priority policy with varying priority. The priority of security-related flow records...
>
> (The only thing the protocol specifies with respect to PR usage is that templates MUST be reliably, otherwise things break badly; it turns out that in a lot of applications billing records are relatively low priority, because you can lose a lot of them before it actually changes who pays what.)
>
>> with full reliability whereas security related flow-records and monitoring
>> flow-records would be sent using the Priority Policy. The priority of
>> security related flow-records would be chosen higher than the the priority
>> of monitoring flow records.</t>
>> I also added the sentence
>>
>> User messages sent reliable are considered having a priority higher than
>> all messages sent with the Priority Policy.
>>
>> to make clear that sending a reliable message might result in abandoning messages
>> send with Priority policy, no matter what the provided priority is.
> Yep, that's good. (I had assumed this is the case, but making it explicit is better).
>
> Cheers,
>
> Brian
>
>>> I believe that you now understand the background of my first question in my initial COMMENT, for which I had RFC 6526 in mind:
>>> 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?
>>>>
>>> Being specific might be usefull: there are no limitations per stream.
>>> NEW:
>>> 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 the same or a different stream) with a priority
>>> lower than the provided one.
>> Text taken.
>>
>> Best regards
>> Michael
>>> Regards, Benoit
>>>> Best regards
>>>> Michael
>>>>
>>>>> Cheers,
>>>>>
>>>>> Brian
>>>>>
>>>>>
>>>>>
>>>>>> Currently this is left implementation specific. So if choosing from the same stream is important,
>>>>>> we might want to add a sentence saying this.
>>>>>>
>>>>>> Thanks for jumping in...
>>>>>>
>>>>>> Best regards
>>>>>> Michael
>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Brian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Best regards
>>>>>>>> Michael
>>>>>>>>
>>>> .
> .
>