Re: [IPFIX] TCP flags?

Hi all,

I've been on vacation so let me recap and make sure I have all the 
options straight.

Options
1) add ECE and CWR bits to the current definition with a note that " 
Collecting Processes should not assume that CWR and ECE were not set 
simply because they're exported as 0, as previous revisions of the 
Information Element did not include them".

2) update the current definition to unsigned 16 with similar wording to 
option 1 if the 8bit reduced size encoding is exported.   Using the 
extended 16 bits would allow the export of ECN Nonce Sum and remove the 
ambiguity about CWR and ECE that exists in the 8 bit export.

3) Deprecate current IE and replace it with a new 16 bit IE.


Assuming I got the above correct here are my thoughts.

If we are going to make the changes for option 1 we might as well go all 
the way to option 2.  We've covered this before, but having separate 
data types for different integer lengths is pretty much pointless since 
the size is always exported in the template.  From a collector stand 
point I pretty much have to respect the length in the template so 
increasing this to a unsigned 16 is no real work for me.

The only real difference I see between options 2 and 3 is that the 
reduced size encoding for option 2 will always be ambiguous for two 
bits.  I don't yet have an opinion on how big a deal that is. Can we 
increase the size of the current TCP flags and deprecate the export of 
the reduced size encoding?

I currently have a very slight preference for option 2 (with or without 
deprecating reduced size encoding), but there is still a quite, but 
persistent, voice in the back of my head saying option 3 is "the right 
thing".

-Andrew



On 07/19/2013 10:01 AM, Paul Aitken wrote:
> Brian,
>
> So we have at least 3 solutions. We need a wider audience and feedback 
> from collector vendors.
>
> P.
>
>
> On 19/07/13 14:51, Brian Trammell wrote:
>> Hi Paul,
>>
>> Inline, sent from my iPhone
>>
>> On 19.07.2013, at 15:26, Paul Aitken <[email protected]> wrote:
>>
>>> Brian,
>>>
>>>> hi Paul,
>>>>
>>>> another idea inline.
>>>>
>>>> On 19 Jul 2013, at 14:48 , Paul Aitken <[email protected]> wrote:
>>>>>>> Q2: how should the ECN Nonce Sum be reported?
>>>>>> My suggestion would be to define this field as an unsigned16:
>>>>>>
>>>>>> MSb LSb
>>>>>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
>>>>>>     |                           | N | C | E | U | A | P | R | S | 
>>>>>> F |
>>>>>>     |         Reserved          | S | W | C | R | C | S | S | Y | 
>>>>>> I |
>>>>>>     |                           |   | R | E | G | K | H | T | N | 
>>>>>> N |
>>>>>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
>>>>>>
>>>>>> with a specific note that when the IE is encoded as an unsigned8 
>>>>>> using reduced-length encoding, it has the following layout:
>>>>>>
>>>>>>      MSb                         LSb
>>>>>>     +---+---+---+---+---+---+---+---+
>>>>>>     | C | E | U | A | P | R | S | F |
>>>>>>     | W | C | R | C | S | S | Y | I |
>>>>>>     | R | E | G | K | H | T | N | N |
>>>>>>     +---+---+---+---+---+---+---+---+
>>>>>>
>>>>>> and a further specific note that Collecting Processes should not 
>>>>>> assume that CWR and ECE were not set simply because they're 
>>>>>> exported as 0, as previous revisions of the Information Element 
>>>>>> did not include them.
>>>>>>
>>>>>> Yes, it's kludgy, but it has the advantage of describing the 
>>>>>> reality of the status quo.
>>>>> I'm happy with that, except for enlarging the size from u8 to u16. 
>>>>> Is that acceptable to collectors?
>>>> As far as I can tell, that's the only open question.
>>>>
>>>> Another possibility: expand this one to the full 8 bits (with a 
>>>> note about CWR and ECE being potentially unsupported by old EPs), 
>>>> and define a new unsigned8 IE for the high four bits of the 
>>>> increasingly inaccurately named TCP flags byte, to futureproof 
>>>> against use of those three bits.
>>>>
>>>> This has the advantage of having the same record encoding as the 
>>>> unsigned16 version (if you follow tcpHighControlFlags with 
>>>> tcpControlFlags in the template) at the expense of 4 extra template 
>>>> bytes, while not having any possibility to break collectors that 
>>>> aren't expecting it.
>>> Yes, that would work too.
>>>
>>> It'd be slightly more efficient to define the new field as u16 
>>> containing all the bits, and export either/or.
>>>
>>> A collector update is required either way...
>> Not if an exporter that's ECN Nonce aware is exporting to a collector 
>> that isn't; in that case, it gets the low 8 bits from the 
>> tcpControlBits and the ignores the high four (one) as an unknown IE.
>>
>> Cheers B
>
> _______________________________________________
> IPFIX mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipfix

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