Re: [IPFIX] New Version Notification for draft-trammell-ipfix-tcpcontrolbits-revision-00.txt

On 09/10/2013 07:11 AM, Brian Trammell wrote:
> On 10 Sep 2013, at 10:32 , Lothar Braun <[email protected]> wrote:
[ snip ]
> I'm a big fan of "each IE means one thing", even at the expense of
> efficiency, especially as these IEs are beginning to 

+1

> see use outside IPFIX. But it's entirely possible if unlikely that at
> some point in the future we'll reuse these four bits 

Where else?  Just curious.

> for something else, at which point the solution is a matter for the
> people writing the redefinition, and will probably look a lot like
> what we did for the ECN flag bits.
>> What I would like to have would be some text that sets the bits to reserved and says something like:
>>
>> "Bits 0x1000 through 0x.8000 are reserved for future use. A collector must not assume to receive information about the TCP header length; the field tcpHeaderLength Information Element should be used to encode this value."
>>
>> What do you think?
> Again, I'm not sure that I'd want to explicitly encourage such reuse.

I'd go one step stronger and say such reuse should be actively discouraged.

[ snip ]

>>> this
>>>      Information Element covers the low-order octet of this field (i.e,
>>>      bits 0x80 to 0x01), omitting the ECN Nonce Sum and the three
>>>      Future Use bits.  A collector receiving this Information Element
>>>      with reduced length encoding must not assume anything about the
>>>      content of these four bits.
>> I just wanted to raise this point (without objecting). This would clearly be an exception to what I would expect from reduced size encoding in RFC 5101bis:
>>
>>   The reduction in size can be to any number of
>>   octets smaller than the original type if the data value still fits,
>>   i.e., so that only leading zeroes are dropped.
>>
>> Whenever I see reduced size encoding, I assume that there is no further information in the field and that all leading bits are zero because of this text. But I would assume this is not a hard requirement from RFC 5101(bis), and it is probably ok if the data type has an explicit definition that states that the first bits are not zero.
> Well, it could mean two things: the top bits are zero because the Nonce Sum bit was never set on any packet in the flow (which, given studies on the usage of ECN, and anecdotes about ECN Nonce deployment, I would say is the case 99.99...% of the time), or because it was not observed (since nobody uses ECN nonce, nobody measures it, either).
>
> Perhaps we should state that unsigned16 encoding should ONLY be used by EPs connected to MPs which actually know how to measure at least one of the bits, so that 0s here won't be interpreted as actual assertions of no flag present.

I like this idea.  It provides an avenue to reduce/remove ambiguity.

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