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

From: "Benoit Claise" <[email-masked]>
Date: Tue, 03 Feb 2015 09:05:08 -0800

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

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?

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.

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 3 Feb 2015 18:25:16 +0100

> On 03 Feb 2015, at 18:05, Benoit Claise <[email-masked]> wrote:
> 
Hi Benoit,

thanks a lot for the review. See my comments in-line.

Best regards
Michael
> association? Or is this implementation specific?
As specified above: It is only from the same association. Normally the
buffering is done per socket.
> 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.

Best regards
Michael

---

From: Brian Trammell <[email-masked]>
Date: Tue, 3 Feb 2015 18:57:37 +0100

hi Benoit, all,

I can perhaps shed a light on this point, inline below:

> On 03 Feb 2015, at 18:25, Michael Tuexen <[email-masked]> wrote:
> 

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.

Cheers,

Brian

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 3 Feb 2015 19:09:07 +0100

> On 03 Feb 2015, at 18:57, Brian Trammell <[email-masked]> wrote:
> 
> hi Benoit, all,
> 
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. 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

---

From: Brian Trammell <[email-masked]>
Date: Tue, 3 Feb 2015 19:18:47 +0100

Hi Michael,

Sent from my iPhone

On 03 Feb 2015, at 19:09, Michael Tuexen <[email-masked]> wrote:

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

Cheers, 

Brian

> Currently this is left implementation specific. So if choosing from the same stream is important,

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 3 Feb 2015 19:21:10 +0100

> On 03 Feb 2015, at 19:18, Brian Trammell <[email-masked]> wrote:
> 
> Hi Michael,
> 
> Sent from my iPhone
> 
This means we can abandon messages from other streams, so we can leave the selection of the messages to
abandon implementation dependent. Something I would prefer.

Best regards
Michael

---

From: Benoit Claise <[email-masked]>
Date: Wed, 04 Feb 2015 14:45:20 +0100

On 03/02/2015 18:57, Brian Trammell wrote:
> None of this makes it clear from looking at the *documents* why all of this makes sense,
Exactly. I struggled exactly on that point.
I believe this explanation is required.
> but we could add a sentence explaining this to the prpolicies draft.
Either how it could be used in IPFIX today or a different example.

Regards, Benoit
> .

---

From: Benoit Claise <[email-masked]>
Date: Wed, 04 Feb 2015 15:00:26 +0100

On 03/02/2015 19:21, Michael Tuexen wrote:
> This means we can abandon messages from other streams,
Yes.
> so we can leave the selection of the messages to
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.

>      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

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 5 Feb 2015 10:10:39 +0100

> On 04 Feb 2015, at 15:00, Benoit Claise <[email-masked]> wrote:
> 
>>> On 03 Feb 2015, at 19:09, Michael Tuexen 
>>> <[email-masked]>
>>>  wrote:
>>> 
>>> 
>>>>>>> On 03 Feb 2015, at 18:05, Benoit Claise 
>>>>>>> <[email-masked]>
>>>>>>>  wrote:
>>>>>>> 
>>>>>>> Please refer to 
>>>>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>>>> 
> 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.
> 
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
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.
> 
> 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.
Text taken.

Best regards
Michael

---

From: Brian Trammell <[email-masked]>
Date: Thu, 5 Feb 2015 10:22:33 +0100

hi Michael,

This is good, though I'd tweak it slightly...

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

> 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

---

From: Benoit Claise <[email-masked]>
Date: Thu, 05 Feb 2015 16:19:08 +0100

Michael, Brian,

I like your two combined proposals.

Thanks and regards, Benoit

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 5 Feb 2015 17:25:45 +0100

> On 05 Feb 2015, at 10:22, Brian Trammell <[email-masked]> wrote:
> 
> hi Michael,
> 
Thanks a lot, text taken.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 5 Feb 2015 17:26:50 +0100

> On 05 Feb 2015, at 16:19, Benoit Claise <[email-masked]> wrote:
> 
> Michael, Brian,
> 
Great, the text will be in the next revision. Thanks a lot for the fast responses.

Best regards
Michael