Re: Proposed changes to make tcp.ack and tcp.seq relative

[Peter Wu <peter () lekensteyn nl>]

On Tue, May 05, 2020 at 08:59:45AM -0400, Lee wrote:
> On 5/4/20, Peter Wu <peter () lekensteyn nl> wrote:
> > Hi all,
> >
> > A request was filed earlier to add a new "tcp.ack_rel" field to ensure
> > that color filters can be created that always work on the relative
> > sequence numbers independent of the "Relative sequence numbers" option.
> > Instead of adding a new field, I propose to change the existing ones.
>
> I prefer non-breaking changes and this sounds like it's going to break
> at least my setup.

I am aware it is user-visible, but I hope it is for good. How exactly
would it break?

> How hard is it to add a new field?

There is a non-zero cost. My primary concern is that -Tpdml and maybe
-Tjson outputs get even bigger than they already are.

> How hard is it to change the existing fields only if the user wants
> relative sequence numbers & leave them alone if they do not want
> relative sequence numbers: ie.
> tcp.relative_sequence_numbers: FALSE

The aim was to make tcp.seq/tcp.ack provide the relative sequence
numbers independent of the preference, so it would not be possible
unless the proposal is rejected. For use cases, see
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16515

> How much of the following breaks if you change the existing fields:
> column.width:
>   ...
>         "%Cus:tcp.seq", 80,
>         "%Cus:tcp.nxtseq", 80,
>         "%Cus:tcp.ack", 80,

If you intend to always display raw numbers, you have to replace
"tcp.seq" by "tcp.seq_raw" and "tcp.ack" by "tcp.ack_raw". You do raise
a very interesting case, "tcp.nxtseq" currently does not have a
"tcp.nxtseq_raw" variant and I don't think that changing this to always
become relative is a good idea.

With that issue and the problem of breaking existing workflows, I think
that I will drop the proposal.

The next question is whether "tcp.seq_rel" and "tcp.ack_rel" fields are
needed? There are patches in review that add options to specifically
recognize TCP Fast Open. One hypothetical case was raised, but if there
are no real-world use cases I would prefer not adding a new field.

Thanks for your feedback!
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe