Re: [IPFIX] layer7OctetDeltaCount / layer7PacketDeltaCount
Brian Trammell <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
Paul, On 17 Jun 2013, at 14:26 , Paul Aitken <[email protected]> wrote: > Brian, > > This implies that we should rename the existing "octetDeltaCount" (#1) and "packetDeltaCount" (#2) IEs to clearly express that these are layer 3 observations. eg, "networkOctetDeltaCount" and "networkPacketDeltaCount". Well, we could, though I think it would be a waste of time. I don't think it would add any clarity: the descriptions define the IEs, and they're fine. > Else one could argue that a "transport layer observation point" should export #1 and #2 rather than the new IEs you propose below. If we had a concept for "transport layer observation point," which we don't. Given that we don't have a way to dimension IEs yet, and we won't for a while, this is the best proposal I can come up with to interoperably represent "octets above the transport header" and "packets with octets above the transport header". Regards, Brian > On 17/06/13 13:09, Brian Trammell wrote: >> Hi, all, >> >> Coming back to this one, seeing the obvious difficulty with addressing layers above 4 by number, and thinking about how to handle the naming issue otherwise, I amend my previous proposal to: >> >> >> Element ID: TBA >> Name: transportOctetDeltaCount >> Data Type: unsigned64 >> Semantics: deltaCounter >> Description: >> >> The number of octets, excluding IP header(s) and Layer 4 transport protocol header(s), observed for this Flow at the Observation Point since the previous report (if any). >> >> >> Element ID: TBA >> Name: transportPacketDeltaCount >> Data Type: unsigned64 >> Semantics: deltaCounter >> Description: >> >> The number of packets containing at least one octet beyond the IP header(s) and Layer 4 transport protocol header(s), observed for this Flow at the Observation Point since the previous report (if any). >> >> Thoughts? >> >> Cheers, >> >> Brian >> >> On 23 May 2013, at 11:47 , Brian Trammell <[email protected]> wrote: >> >>> Hi, Paul, all, >>> >>> >>> On 23 May 2013, at 11:40, Paul Aitken <[email protected]> wrote: >>> >>>> Brian, >>>> >>>>> I would like to hear the community's opinion on the utility of the following two _new_ Information Elements. >>>>> >>>>> >>>>> Element ID: TBA >>>>> Name: layer7OctetDeltaCount >>>>> Data Type: unsigned64 >>>>> Semantics: deltaCounter >>>>> Description: >>>>> >>>>> The number of octets, excluding IP header(s) and Layer 4 transport protocol header(s), observed for this Flow at the Observation Point since the previous report (if any). >>>>> >>>>> >>>>> Element ID: TBA >>>>> Name: layer7PacketDeltaCount >>>>> Data Type: unsigned64 >>>>> Semantics: deltaCounter >>>>> Description: >>>>> >>>>> The number of packets containing at least one octet beyond the IP header(s) and Layer 4 transport protocol header(s), observed for this Flow at the Observation Point since the previous report (if any). >>>> Using "layer 7" in the name and "layer 4" in the definition leaves it unclear whether layer 6 should be included. >>> Point. What's layer 6 in the IETF IP stack, though? >>> >>> Let's back off from layering for a moment. How about "transportedOctetDeltaCount"? >>> >>> The packet IE naming is harder though. "nonemptyPacketDeltaCount"? >>> >>>> Yesterday I got to wondering what exactly a layer 4 packet is. Put another way, how often do we send packets which don't have any layer 4 content? Now I'm wondering the same about layer 7 - ie, what sort of packets would - and more importantly _would not_ - be counted by layer7PacketDeltaCount ? >>> All the time. TCP handshakes and pure ACKs, for one (these are the ones I care about). SCTP control chunks. >>> >>>> BTW, recall the Extended Field Specifier Format? How useful if all these IEs could be grouped under a single pair of "packetCount" and "octetCount" IEs with multiple extensions, eg packetCount.{layerN}.{delta|total}. >>> That'd be great. However, I'd like to implement these counters well before the complete revision of the Information Model implied by Extended Field Specifiers is complete. >>> >>> Cheers, >>> >>> Brian >>> _______________________________________________ >>> IPFIX mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/ipfix >> _______________________________________________ >> IPFIX mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipfix