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

[Michael Tuexen <[e-mail]>]

> On 05 Feb 2015, at 10:22, Brian Trammell <[e-mail]> wrote:
> 
> 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...
Thanks a lot, text taken.

Best regards
Michael
> 
> (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
>>>>>>>> 
>>>> .
> 
>