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

[Benoit Claise <[e-mail]>]

On 03/02/2015 19:21, Michael Tuexen wrote:
>> On 03 Feb 2015, at 19:18, Brian Trammell <[e-mail]> wrote:
>>
>> Hi Michael,
>>
>> Sent from my iPhone
>>
>> On 03 Feb 2015, at 19:09, Michael Tuexen <[e-mail]> wrote:
>>
>>>> On 03 Feb 2015, at 18:57, Brian Trammell <[e-mail]> 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, but we could add a sentence explaining this to the prpolicies draft.
>>> Does this mean that when you send a high priority message on stream 10, that out only want to abandon
>>> lower priority messages of that stream or is it OK to abandon also lower priority messages from other
>>> streams.
>> This is my personal interpretation of the intent of 7011 only... but the only guarantee that IPFIX requires of SCTP with respect to streams (when not using 6526, which also further restricts what the EP can do) is that messages on a stream arrive in the order in which they are sent. This is important for templates, which must be sent fully reliably (i.e. max prio) anyway. So I see no reason not to leave this up to the implementation.
> This means we can abandon messages from other streams,
Yes.
> so we can leave the selection of the messages to
> abandon implementation dependent. Something I would prefer.
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.

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.

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