Re: [tipc-discussion] Should we obsolete the short message header in TIPC 2.0?

[Jon M. <jon...@er...>]

Hi Allan,
The short header was introduced as an extreme optimization feature, since information about originating node/port is already known by the receiving endpoint. I see it as a functionally exceptional case which is statistically overwhelmingly dominant in the traffic flow, and therefore motivated.
Apart from having the advantage that there are eight fewer bytes to transfer and copy, it also makes any check for message type redundant at the receiving end. The fact that the header is 24 bytes long implicitly tells the receiver that it is a CONN_MSG and who the sender is.

That said, I am not necessarily against such a simplification, if it has no measurable impact on intra-node and inter-node peformance. I suspect that is the case in the current Linux implementation.

Run the benchmark test with both header sizes, and if there is no difference, I favour your suggestion.

Regards
///jon



Jon Maloy M.Sc. EE
Researcher
Ericsson Canada
Broadband and Systems Research
8400 Decarie
H4P 2N2, Montreal, Quebec, Canada
Phone + 1 514 345-7900 x42056
Mobile + 1 514 591-5578
jon...@er...
www.ericsson.com



________________________________
From: Stephens, Allan [mailto:all...@wi...]
Sent: March-31-11 17:19
To: Jon Maloy
Cc: tip...@li...
Subject: Should we obsolete the short message header in TIPC 2.0?

Hi Jon:

In my continuing efforts to simplify things in TIPC 2.0 I was wondering if it would make sense to obsolete the use of the 24 byte message header for connection-based payload messages, and have TIPC 2.0 always use the 32 byte header form (as it does for connectionless payload messages that don't use naming).

My main objection to the status quo is that it's inconsistent for TIPC to use two different header formats for the connection-based and unnamed connectionless payload messages. Why should the connectionless payload message always have to specify an originating and destination node while the connection-based message only does so for inter-cluster connections? It seems more logical to insist that either: a) those fields be supplied in all cases, or b) those fields should only be supplied for inter-cluster traffic. Since approach a) would probably cause fewer backwards compatibility issues, and would likely simplify coding a bit, that's probably the way we should go.

I should also point out that TIPC is currently also inconsistent in its use of the short header form since there are a few places in which intra-cluster connection-based payload messages get sent out with the 32 byte header, such as when a short form message is rejected because it is undeliverable and when TIPC sends out a FIN message to abort an established connection. Once again, standardizing TIPC 2.0 to use the 32 byte header seems like the right way to address this inconsistency.

Of course, obsoleting the 24 byte message header in TIPC 2.0 doesn't mean that TIPC 2.0 wouldn't be able to handle incoming messages using this form - just that it wouldn't send any. We'll obviously need to continue supporting the short header form so that TIPC 2.0 can interoperate with existing

Your thoughts?

Regards,
Al