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 16:19, Benoit Claise <[e-mail]> wrote:
> 
> Michael, Brian,
> 
> I like your two combined proposals.
Great, the text will be in the next revision. Thanks a lot for the fast responses.

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