Subject: [IPFIX] Fwd: initiatorOctets/initiatorPackets/responderOctets/responderPackets change

From: Brian Trammell <[email-masked]>
Date: Fri, 17 May 2013 09:45:31 +0200

Oops, hit reply instead of reply all...

Begin forwarded message:

> From: Brian Trammell <[email-masked]>
> Subject: Re: [Sender: [email-masked]] [IPFIX] initiatorOctets/initiatorPackets/responderOctets/responderPackets change
> Date: 16 May 2013 19:22:10 GMT+02:00
> To: Paul Aitken <[email-masked]>
> 
> Hi, Paul,
> 
> Indeed, decrement the numbers in the definition.
> 
> "app" is intended to abbreviate "application". Not a huge fan of this name, but I can't come up with anything more precise that isn't significantly longer. "layer7"? "overTransport"? "transported"? 
> 
> Regards,
> 
> Brian
> 
> Sent from my iPhone
> 
> On 16.05.2013, at 18:10, Paul Aitken <[email-masked]> wrote:
> 
>> Brian,
>> 
>> 1. Some mistake in the numbering in your new definitions: you've written 232 and 233 instead of 231 and 232.
>> 
>> 2. What's the significance of "app" in these names? "Applicable"? "Application"? "Appearing"? "Appended"? "Approved"? "Appropriate"? "Approximate"? ...
>> 
>> P.
>> 
>> 
>> On 16/05/13 16:45, Brian Trammell wrote:
>>> Greetings, all,
>>> 
>>> Following a previous suggestion to update  propose we modify the names and definitions of the initiatorOctets(231), responderOctets(232), initiatorPackets(298), and responderPackets(299) as follows, (1) to bring them in line with the naming of other IPFIX Information Elements, (2) to allow them to be used by RFC 5103-compliant biflow Exporting Processes, and (3) to ensure (especially in the case of 298 and 299) that the descriptions are interoperably implemented.
>>> 
>>> I think the proposed descriptions reflect the intent of the present descriptions, within the context of RFC 5103 terminology, and should therefore not have any impact on interoperability; I note that the description of IEs 298 and 299 are, however, not decipherable as written, so I may be taking some necessary liberty with my interpretation.
>>> 
>>> 
>>> Element ID: 232
>>> Name:       appOctetDeltaCount
>>> 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: 233
>>> Name:       reverseAppOctetDeltaCount
>>> Data Type:  unsigned64
>>> Semantics:  deltaCounter
>>> Description:
>>> 
>>> The number of octets, excluding IP header(s) and Layer 4 transport protocol header(s), observed for the reverse direction of this Flow, as defined in RFC 5103, at the Observation Point since the previous report (if any). If present in a Flow Record along with appOctetDeltaCount, causes appOctetDeltaCount to refer to the forward direction of the Flow. If present in a Flow Record, implies that that Flow Record is exported with direction assigned by the initiator (as in section 5.1 of RFC 5103), unless contradicted by a biflowDirection Information Element present in the Flow Record or otherwise applicable to the Flow Record's scope.
>>> 
>>> 
>>> Element ID: 298
>>> Name:       appPacketDeltaCount
>>> 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).
>>> 
>>> 
>>> Element ID: 299
>>> Name:       reverseAppPacketDeltaCount
>>> 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 the reverse direction of this Flow, as defined in RFC 5103, at the Observation Point since the previous report (if any). If present in a Flow Record along with appPacketDeltaCount, causes appPacketDeltaCount to refer to the forward direction of the Flow. If present in a Flow Record, implies that that Flow Record is exported with direction assigned by the initiator (as in section 5.1 of RFC 5103), unless contradicted by a biflowDirection Information Element present in the Flow Record or otherwise applicable to the Flow Record's scope.
>>> 
>>> 
>>> Following discussion on the list, I intend to submit this proposed change to the IE-DOCTORS for review.
>>> 
>>> Thoughts?
>>> 
>>> Many thanks, best regards,
>>> 
>>> Brian
>>> _______________________________________________
>>> IPFIX mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Andrew Feren <[email-masked]>
Date: Fri, 17 May 2013 10:10:49 -0400

Hi Brian,

If you are looking for consistency I'd go with "layer7".  There are 
already 3 "layer2" IEs including 2 octet counts (layer2OctetDeltaCount 
and layer2OctetTotalCount).

Also the the table of values for classificationEngineId (101) all use L# 
or layer # in their descriptions.

-Andrew

---

From: Brian Trammell <[email-masked]>
Date: Fri, 17 May 2013 16:33:52 +0200

Hi, Andrew.

Hm... Good point. Thanks.

(Pedantically: "everything under Layer 4" might also include layer 5 -- if you're of the opinion that HTTP is really a session layer nowadays -- but I think most everyone will understand what is meant.)

So I amend my proposal to:

Element ID: 231
Name:       layer7OctetDeltaCount
Data Type:  unsigned64
Semantics:  deltaCounter
Description:

Element ID: 232
Name:       reverseLayer7OctetDeltaCount
Data Type:  unsigned64
Semantics:  deltaCounter
Description:

The number of octets, excluding IP header(s) and Layer 4 transport protocol header(s), observed for the reverse direction of this Flow, as defined in RFC 5103, at the Observation Point since the previous report (if any). If present in a Flow Record along with layer7OctetDeltaCount, causes layer7OctetDeltaCount to refer to the forward direction of the Flow. If present in a Flow Record, implies that that Flow Record is exported with direction assigned by the initiator (as in section 5.1 of RFC 5103), unless contradicted by a biflowDirection Information Element present in the Flow Record or otherwise applicable to the Flow Record's scope.

Element ID: 298
Name:       layer7PacketDeltaCount
Data Type:  unsigned64
Semantics:  deltaCounter
Description:

Element ID: 299
Name:       reverseLayer7PacketDeltaCount
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 the reverse direction of this Flow, as defined in RFC 5103, at the Observation Point since the previous report (if any). If present in a Flow Record along with layer7PacketDeltaCount, causes layer7PacketDeltaCount to refer to the forward direction of the Flow. If present in a Flow Record, implies that that Flow Record is exported with direction assigned by the initiator (as in section 5.1 of RFC 5103), unless contradicted by a biflowDirection Information Element present in the Flow Record or otherwise applicable to the Flow Record's scope.

Cheers,

Brian

On May 17, 2013, at 4:10 PM, Andrew Feren <[email-masked]> wrote:

> Hi Brian,
> 
> If you are looking for consistency I'd go with "layer7".  There are already 3 "layer2" IEs including 2 octet counts (layer2OctetDeltaCount and layer2OctetTotalCount).
> 
> Also the the table of values for  classificationEngineId (101) all use L# or layer # in their descriptions.
> 
> -Andrew
> 
> 
> 
>>> Subject: Re: [Sender: 
>>> [email-masked]
>>> ] [IPFIX] initiatorOctets/initiatorPackets/responderOctets/responderPackets change
>>> On 16.05.2013, at 18:10, Paul Aitken 
>>> <[email-masked]>
>>>  wrote:
>>> 
>>> 
>>>> Brian,
>>>>

---

From: Paul Aitken <[email-masked]>
Date: Wed, 22 May 2013 12:57:33 +0100

Brian,

The existing IANA definitions and cisco definitions of these fields are 
in terms of "layer 4". I believe it's wrong to rename them to "layer7".

There would be a difference between the "layer 4" and "layer 7" 
definitions if there's layer 6 encryption or EBCDIC/ASCII conversion.

These fields were requested by cisco; they're documented in Appendix A here:
http://www.cisco.com/en/US/docs/ios/solutions_docs/avc/ios_xe3_8/avc_soln_guide_iosxe3_8_full.pdf

Although that doesn't give us ownership of these fields, if you change 
them then we'll no longer be compliant with the fields we requested :-(

P.

---

From: Brian Trammell <[email-masked]>
Date: Thu, 23 May 2013 11:25:42 +0200

hi, Paul, all,

On 22 May 2013, at 13:57, Paul Aitken <[email-masked]> wrote:

> Brian,
> 
> The existing IANA definitions and cisco definitions of these fields are in terms of "layer 4". I believe it's wrong to rename them to "layer7".
> 
> There would be a difference between the "layer 4" and "layer 7" definitions if there's layer 6 encryption or EBCDIC/ASCII conversion.

I have the same problem with naming them layer7, actually. They're _not_ "layer4", though, since they count octets above the layer 4 headers. I suppose we could call them layer5, but that would almost certainly confuse everyone. Whether it would be more or less confusing than the _current_ names, though, I'm not sure.

> Although that doesn't give us ownership of these fields, if you change them then we'll no longer be compliant with the fields we requested :-(

As specified, these four IEs that can never be unambiguously implemented by an RFC 5103 EP, since the presence of these IEs may or may not reverse the sense of forward and reverse direction. (There is a separate issue here, that 298 and 299 are presently so unclearly specified in my opinion as to be completely unimplementable. This will need to be fixed, but we can set that aside for the moment.) We certainly don't want to break existing implementations (any revision, per ie-doctors, must be interoperable; breaking existing implementations would not be).

I'd thought that the intent of these IEs was to implement something similar to what I'd proposed to change the descriptions to. This would appear not to be the case. Since we have an RFC 5103 EP, on which these IEs are not implementable, and we need to export the fields as specified in my proposal, I withdraw my request to consider the redefinition of these four IEs; we simply won't use them. However, I would like to hear the community's opinion on the utility of the following two _new_ Information Elements.

Element ID: TBA

Element ID: TBA

(We intend to use 5103 as specified for the reverse directions thereof).

Brian

---

From: Paul Aitken <[email-masked]>
Date: Thu, 23 May 2013 10:40:35 +0100

Brian,

> I would like to hear the community's opinion on the utility of the following two _new_ Information Elements.
>
>
> Element ID: TBA

Using "layer 7" in the name and "layer 4" in the definition leaves it 
unclear whether layer 6 should be included.

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 ?

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

P.

---

From: Brian Trammell <[email-masked]>
Date: Thu, 23 May 2013 11:47:22 +0200

Hi, Paul, all,

On 23 May 2013, at 11:40, Paul Aitken <[email-masked]> wrote:

> 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