Subject: Re: [IPFIX] review of draft-ietf-ipfix-mediation-protocol-04

From: Paul Aitken <[email-masked]>
Date: Mon, 01 Jul 2013 11:03:09 +0100

Brian, replies inline:

>>>>>     Original Exporter:   An Original Exporter is an IPFIX Device that
>>>>>        hosts the Observation Points where the metered IP packets are
>>>>>        observed.
>>>>>
>>>>>     Original Observation Point:   An Observation Point of the Original
>>>>>        Exporter.  In the case of the Intermediate Aggregation Process on
>>>>>
>>>> These definitions imply that OPs belong to the exporter, which is not the case; they belong to the MP or to the IPFIX device.
>>> Changed to
>>> Original Observation Point:   An Observation Point on
>>> the Original
>>>        Exporter.  In the case of the Intermediate Aggregation Process on
>>>
>> Looking at the OP and OD definitions in 5101 and 5101bis, I see nothing to suggest that OPs are in any way related to Exporters.
> Yes, but from the point of view of a Mediator, the Original Observation Point is defined in terms of its relationship to the Original Exporter, no? So this seems fine.

Disagree. If multiple Metering Processes export through a single 
Exporting Process, a Mediator will only know a single Original Exporter. 
However, it's important to distinguish that the OPs belong to different 
original MPs. It's incorrect for a mediator to assume that they're all 
in a single space simply because they're reported by the same OE. If 
that wasn't true, we wouldn't have any need for Observation Domain.

>>>> So are we saying that OD zero has a special meaning? Should existing exporters avoid using OD zero in order to avoid confusing Collectors?
>>> It's already taken care of by RFC5101bis and RFC5101 btw.
>>>   Observation Domain ID
>>>
>>>        A 32-bit identifier of the Observation Domain that is locally
>>>        unique to the Exporting Process.  The Exporting Process uses the
>>>        Observation Domain ID to uniquely identify to the Collecting
>>>        Process the Observation Domain that metered the Flows.  It is
>>>        RECOMMENDED that this identifier also be unique per IPFIX Device.
>>>        Collecting Processes SHOULD use the Transport Session and the
>>>        Observation Domain ID field to separate different export streams
>>>        originating from the same Exporter.
>>>   The Observation Domain ID
>>>        SHOULD be 0 when no specific Observation Domain ID is relevant for
>>>        the entire IPFIX Message, for example, when exporting the
>>>        Exporting Process Statistics, or in case of a hierarchy of
>>>        Collectors when aggregated Data Records are exported.
>>>
>>> Now, the only change is SHOULD -> MUST
>> You avoided the second part of the question: Should existing exporters avoid using OD zero in order to avoid confusing Collectors?
>>
>> I could also ask, "MUST existing exporters avoid using OD zero ..." ?
>>
>> It's possibly not directly relevant for this draft, but definitely for 5101bis.
> What's the suggested change to 5101bis? There's no particular guidance to avoid OD zero in cases where the Message doesn't contain data for multiple source ODs, but IIRC we left this (and indeed, everything we could possibly could about ODs) open, because an OD is kind of an opaque thing up to the implementor, and only touches the protocol in that it scopes templates and options.

It's opaque apart from the recently introduced special value, zero. When 
a mediator or collector sees OD zero, it can't tell whether the export 
came from a simple device with only one OD, or from a complex device 
with multiple ODs using the "no specific Observation Domain ID is 
relevant" rule.

>>>>> Claise, et al.           Expires August 29, 2013               [Page 22]
>>>>> Internet-Draft               IPFIX MED-PROTO               February 2013
>>>>>
>>>>>
>>>>>     | ignoredRecordTotalCount | The total number of Data Records        |
>>>>>     |                         | received but not processed by the       |
>>>>>     |                         | Intermediate Process.                   |
>>>>>     | time first record       | The timestamp of the first record that  |
>>>>>     | ignored                 | was ignored by the Intermediate         |
>>>>>     |                         | Process.  For Data Records containing   |
>>>>>     |                         | timestamp ranges, this SHOULD be taken  |
>>>>>     |                         | from the start timestamp of the range;  |
>>>>>     |                         | for data records containing no timing   |
>>>>>     |                         | information, this SHOULD be taken from  |
>>>>>     |                         | the Export Time in the message header   |
>>>>>     |                         | of
>>>>> the containing IPFIX Message.  For   |
>>>> Is this the incoming IPFIX Message? So the Intermediate Process has to examine each incoming Message in some detail, even though it's ignoring them?
>>> Yes.
>> Well that's just daft. So this is a new definition of "ignoring" which actually means "examining them in detail"? Have you considered a career in politics?
> Yes, but they won't let me run for anything here until I get my passport. ;)
>
> And this depends completely on where the bottleneck is. Consider the case where per-record processing is far more expensive than message deframing, in that case, it knows exactly where in the record stream it starts having problems, and can count dropped records because it's operating on a record stream instead of a message stream. It can even keep deframing messages when it knows that it'll have to drop records, because the marginal cost of deframing a message is zero.
>
> If the problem is keeping up with messages, though, yes, you're right, this doesn't work. See below on the tradition of wild guessing in metameasurement.

A wild guess might be the only possibility.

My concern is that although an implementation may not wish to export 
this option because it cannot be accurately or meaningfully measured, it 
may be obliged to export it for RFC compliance.

>>>>>     |                         | this timestamp, any of the following    |
>>>>>     |                         | timestamp can be used:                  |
>>>>>     |                         | observationTimeSeconds,                 |
>>>>>     |                         | observationTimeMilliseconds,            |
>>>>>     |                         | observationTimeMicroseconds, or         |
>>>>>     |                         | observationTimeNanoseconds.             |
>>>>>     | time last record        | The timestamp of the last record that   |
>>>>>     | ignored                 | was ignored by the Intermediate         |
>>>>>     |                         | Process.  For Data Records containing   |
>>>>>     |                         | timestamp ranges, this SHOULD be taken  |
>>>>>     |                         | from the end timestamp of the range;    |
>>>>>     |                         | for data records containing no timing   |
>>>>>     |                         | information, this SHOULD be taken from  |
>>>>>     |                         | the Export Time in the message header   |
>>>>>     |                         | of the containing IPFIX Message.  For   |
>>>>>     |                         | this timestamp, any of the following    |
>>>>>     |                         | timestamp can be used:                  |
>>>>>     |                         | observationTimeSeconds,                 |
>>>>>     |                         | observationTimeMilliseconds,            |
>>>>>     |                         | observationTimeMicroseconds, or         |
>>>>>     |                         | observationTimeNanoseconds.             |
>>>>>     +-------------------------+-----------------------------------------+
>>>>>
>>>> Pleaseaddsomewhitespacetomakethetablereadable.
>>> I could not find a way to do it...
>> Add some blank lines to vertically separate each definition in the table. Else all the definitions run together.
>>
>> ie, make each definition a visually separate chunk. See http://syque.com/cstyle/ch2.8.htm
> cf. previous discussions on xml2rfc hacking -- as you've made this comment before on stock xml2rfc tables I've put into IPFIX documents, it may be more productive if you raise this issue with the xml2rfc people instead.

I'd need the source XML.

> In the meantime we can certainly crudely hack a dividing line in there.

Thanks.

>>>>> 10.4.  ignoredRecordTotalCount Information Element
>>>>>
>>>>>     Description:   The total number of received Data Records that the
>>>>>        Intermediate Process did not process since the (re-)initialization
>>>>>        of the Intermediate Process; includes only Data Records not
>>>>>        examined or otherwise handled by the Intermediate Process due to
>>>>>        resource constraints, not Data Records which were examined or
>>>>>        otherwise handled by the Intermediate Process but which merely do
>>>>>        not contribute to any exported Data Record due to the operations
>>>>>        performed by the Intermediate Process.
>>>>>
>>>> If a mediator is resource constrained, how can it accurately report this figure?
>>> Like in RFC 5101, section 4.2. The Metering Process Reliability Statistics Option Template
>>>
>>>    ignoredPacketTotalCount
>>>                             The total number of IP packets that the
>>>                             Metering Process did not process.
>>>
>>>     ignoredOctetTotalCount
>>>                             The total number of octets in observed IP
>>>                             packets that the Metering Process did not
>>>                             process.
>>>
>> Sorry, I asked the wrong question. If a mediator is resource constrained, how can it accurately measure this figure?
>>
>> It's a similar point to "time first record ignored" above.
> It can't accurately measure it at all. But that's not the point.
>
> This is simply an instance of the apparent custom in measurement equipment, all the way up and down the stack, to try to estimate dropped/missing packets/messages/events. Some of the estimates (dropped packet counting in hardware capture) are close enough to accurate that you can use them for debug purposes, if not accounting purposes. Some of them are utter garbage. The quality of the guess is implementation and situation dependent. These counters are provided for consistency in line with this tradition: it's the same situation as with reliability statistics reported by MPs and EPs in 5101(bis), of which I'm also (as a user of data) deeply, deeply skeptical. But one can argue that a low-quality, well-intentioned guess is better than nothing.

That's exactly what I'm arguing. Provide an opt-out for the case that an 
implementer knows that this metric will be poor to meaningless, or 
impossible to implement.

P.

---

From: Brian Trammell <[email-masked]>
Date: Mon, 1 Jul 2013 12:51:04 +0200

On 1 Jul 2013, at 12:03 , Paul Aitken <[email-masked]> wrote:

> Disagree. If multiple Metering Processes export through a single Exporting Process, a Mediator will only know a single Original Exporter. However, it's important to distinguish that the OPs belong to different original MPs. It's incorrect for a mediator to assume that they're all in a single space simply because they're reported by the same OE. If that wasn't true, we wouldn't have any need for Observation Domain.

Okay, so the concrete terminological suggestion you're making is...

NEW:
Original Observation Point:   An Observation Point on a Metering 
        Process associated with the Original Exporter...

correct?

> It's opaque apart from the recently introduced special value, zero.

(Where "recent" is "January 2008", with the publication of RFC 5101 (Section 3.1 "Message Header Format", description "Observation Domain ID", bottom of page 12).)

> When a mediator or collector sees OD zero, it can't tell whether the export came from a simple device with only one OD, or from a complex device with multiple ODs using the "no specific Observation Domain ID is relevant" rule.

I don't see the problem here. Why would a CP/mediator need to know something about the OD that the EP didn't export? From the standpoint of the protocol, OD 0 isn't really special -- it's a template and options scope as any other OD, with an added note that the CP should make no assumptions about the uniqueness of flows across records. Any other OD specific behavior is (1) interoperability-irrelevant and (2) implementation-specific.

> My concern is that although an implementation may not wish to export this option because it cannot be accurately or meaningfully measured, it may be obliged to export it for RFC compliance.

Good point. There's 2119 creep here: the reliability records specified in RFC5101 and 5101bis are a MAY, in medproto they're a SHOULD. I suggest the fix here is to downgrade the requirement in section 10 of medproto to MAY:

NEW:

   IPFIX provides Options Templates for the reporting the reliability of
   processes within the IPFIX Architecture.  As each Mediator includes
   at least one IPFIX Exporting Process, they MAY use the Exporting
   Process Reliability Statistics Options Template, as specified in
   [I-D.ietf-ipfix-protocol-rfc5101bis].

   Analogous to the Metering Process Reliability Statistics Options
   Template, also specified in [I-D.ietf-ipfix-protocol-rfc5101bis],
   Mediators MAY implement the Intermediate Process Reliability
   Statistics Options Template, specified in the Section 10.1.

   The Flow Keys Options Template, as specified in
   [I-D.ietf-ipfix-protocol-rfc5101bis], may require special handling at
   an IPFIX Mediator as described in Section 10.2.

> That's exactly what I'm arguing. Provide an opt-out for the case that an implementer knows that this metric will be poor to meaningless, or impossible to implement.

Okay, got it, and I agree. As above, MAY language would provide this opt-out.

Cheers,

Brian

---

From: Paul Aitken <[email-masked]>
Date: Mon, 01 Jul 2013 14:08:36 +0100

Brian,

>          Process associated with the Original Exporter...

That helps.

> (Where "recent" is "January 2008", with the publication of RFC 5101 (Section 3.1 "Message Header Format", description "Observation Domain ID", bottom of page 12).)

2008 wasn't so long ago?

The problem with these RFCs is that they make statements without making 
any implication about the opposite.

eg, the text in question says:

       The Observation
       Domain ID SHOULD be 0 when no specific Observation Domain ID is
       relevant for the entire IPFIX Message, for example, when exporting
       the Exporting Process Statistics, or in case of a hierarchy of
       Collectors when aggregated Data Records are exported.

Normally this would imply that an OD of zero indicates that no specific 
Observation Domain ID is relevant. However I've come to realise that 
it's incorrect to draw this conclusion because the text doesn't 
explicitly say that.

> I don't see the problem here. Why would a CP/mediator need to know something about the OD that the EP didn't export? From the standpoint of the protocol, OD 0 isn't really special -- it's a templat…

You're not concerned about it. I'll let it go.

>     an IPFIX Mediator as described in Section 10.2.

Great.

> Okay, got it, and I agree. As above, MAY language would provide this opt-out.

Thanks,
P.

---

From: Brian Trammell <[email-masked]>
Date: Thu, 4 Jul 2013 17:49:45 +0200

hi Paul, all,

I've made the following changes to the -06 working copy as well

Cheers,

Brian