On Sun, May 12, 2002 at 10:51:09AM +0000, didier wrote:
> Well, png of what I have.
The original time you mentioned this problem, you just referred to the
"protocol hierarchy dialog"; I didn't realize that this was the
statistics dialog, and didn't notice that you mentioned the statistics
dialog later.
The problem there is that the statistics code assumes that top-level
tree item X following top-level tree item Y means that protocol X is
being carried inside protocol Y, not that there are multiple instances
of protocol X in a row.
Thinking about this, however, brings up *another* issue: when reassembly
is being done, the statistics count only the frame that completes the
reassembly, so when reassembly *is* enabled for the sample capture you
sent, it reports three TCP packets, but only one DSI packet, and only
one AFP packet, when, in fact, all three TCP packets contain DSI and AFP
data. I'm inferring that at least one purpose of the statistics is to
tell the user how many link-layer frames carried various protocols, so,
at least in that case, the statistics should count frames, rather than
reassembled packets.
Unfortunately, having a single top-level item for protocol X, with the
various protocol-X packets as subitems under that, doesn't fix that
problem, and has other problems - if the protocol tree were
Frame
Link layer
IP
TCP
DSI
DSI 1
DSI 2
DSI 3
...
where would the AFP packets be put?
Doing
Frame
Link layer
IP
TCP
DSI
DSI 1
DSI 2
DSI 3
...
AFP
AFP 1
AFP 2
AFP 3
...
is a bit ugly, as it doesn't associate a DSI header with the contained
AFP packet, and I'm not sure it'd be easy to implement that, and
Frame
Link layer
IP
TCP
DSI
DSI 1
AFP 1
DSI 2
AFP 2
DSI 3
AFP 3
...
would be a bit ugly, as the AFP stuff wouldn't be at the top level
(which would also mean it wouldn't show up in the protocol statistics), and
Frame
Link layer
IP
TCP
DSI
DSI 1
AFP 1
DSI 2
AFP 2
DSI 3
AFP 3
...
would have the same problem.
In order to fix the reassembly problem I mentioned, we might have to do
the statistics differently - for example, reassembly code might have to
store the total number of frames that contributed to the reassembled
data, and the statistics code might add that to the packet counts.
Unfortunately, TCP reassembly could make that tricky, as you might have
TCP segment 1 containing one higher-level packet and the first half of a
second higher-level packet, TCP segment 2 containing the second half of
that higher-level packet and the first half of a third higher-level
packet, and TCP segment 3 containing the second half of that third
higher-level packet.
Those should, I think, show up in the statistics as
Protocol Packets End Packets
Frame 3 0
Link layer 3 0
IP 3 0
TCP 3 0
XXX protocol 3 3
(I omitted the "bytes" columns - "bytes" is actually easier to deal with
in this case).
However, we'd also have to make sure that
TCP segment 1: 2+1/3 higher-level packets
TCP segment 2: 1/3 higher-level packet
TCP segment 3: 1/3+2+1/2 higher-level packet
TCP segment 4: 1/2+1 higher-level packet
shows up as
Protocol Packets End Packets
Frame 4 0
Link layer 4 0
IP 4 0
TCP 4 0
XXX protocol 4 4
even though there are 7 higher-level packets in the 4 TCP segments.
(We should perhaps also say "Frames" rather than "Packets" in the
protocol hierarchy statistics, to make it clear that it's counting
link-level frames.)