Re: [IPFIX] TCP flags?

Andrew,

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

Another possibility was to add a new IE for the uppermost bits. In some 
cases the two IEs could be exported alongside each other, so the 16 bits 
would be in order (although that need not always be the case).


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

What I said before: changing the size doesn't actually change the type. 
Fundamentally we only have signed and unsigned, in various sizes. If 
we'd recognised this years ago, we wouldn't need the "reduced size 
encoding" rule; collectors would just accept whatever the templates tell 
them.


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

That could work. However, existing implementations would continue to 
export 8 bits, where the top 2 bits are ambiguous.


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

Is it possible that some collectors might break if they receive a field 
with a different size from what 5102 / IANA says? eg, there was a 
problem with old versions of wireshark where it had built-in 
expectations of field sizes, and couldn't cope with the change of 
sampler ID from 8 bits to 16 bits to 32 bits.

If that might be the case, then a new IE is indicated. OTOH, if nobody 
knows of such a possibility, then (2) might work equally as well.

P.


> 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