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

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

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

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?

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

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

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

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.

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

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

Cheers,

Brian
_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix