So, first thing first: I’m not sure there are 100% right answers here, only arguments that we can make because these terms like latency and bitrate do have some amount of ambiguity in common practice. I think I follow your argument. Let me see if I can say it in a different way and you tell me if this is what you mean…
I think there are two important distinctions to make: (1) what is the total amount of time it takes for an entire message to get through to the recipient? (2) What is rate at which bits are sent as part of this system?
“Bitrate” is typically a measurement of the system. So if the students are sending, let’s say, 1 bit per second, then the bitrate is 1 bit per second, no matter how many bits they are sending.
“Latency” is also typically a measurement of the system, not the message, but is a little confusing at this point because the students’ protocol requires this metadata - using AAA and BBB. So you could argue that there is some latency for the message itself – the first bit of the message intended for the recipient starts with the first bit sent after the AAA. If it takes 3 seconds for the AAA to get through, in other words, you could argue that the message latency is 3 seconds.
However, that argument is about the latency of the message, not the system. As a measurement of the system the latency is just 1 second - the amount of time it takes to convey the first bit (which would be the first A of the AAA header).
So, I’m not sure that helps As for your students and their protocol…I would suggest they don’t need the AAA at all. If they know when the starting time is, they can just read the first bit after that point. I would argue they need to know the starting time to detect 3 As in the first place…so they must already be doing this. If they’re already detecting the first bit after the start time, why not just make that the first bit of the message.
As for the end of message…if they can agree as part of their protocol how many bits make up an entire message, then they don’t need the BBB either. If they want a variable-length message though, then having an end-of-message indicator makes sense.
Does this help?