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

[Brian Trammell <[e-mail]>]

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
>>>>>>> 
>>> .