Please clarify queries related to acct.proto file

[kbchandradeep]

Could you please clarify below queries related to acct.proto file. Thank you.

1. As per the proto file, ACK will be sent for a group of accounting records. Since, the connection is over a grpc channel that ensures delivery of the messages, what is the necessity for sending these ACKs?

2. In addition to the ACK sent for a group of accounting records, there is also an ACK sent at least every 60 seconds and the connection gets reset if an ACK is not received for 120 seconds. What is the rationale behind sending this keepalive ACK since there is already ACKs at lower layers (grpc/tcp)?

3. When a record request is received with last message received timestamp, all the messages after the timestamp need to be sent out. This happens when the connection is alive and not during connection initiation. Are there any scenarios where collector asks for the past timestamp because there are chances of retransmission of same packets by accounting service?

4. When a record request is received with zero time, all the messages in the system need to be transmitted. What is the number of messages that we are looking to store in the system?

5. Is it expected to store the messages in the system even after the message is successfully sent out?

6. For accounting push, when the config gets added should the accounting service send a dummy record with just the timestamp to the collector. What will be the response from the collector for this dummy message with timestamp?

7. Required functionality could be achieved with accounting pull alone and there seems to be no necessity for accounting push. For accounting push, accounting service needs to do a dial out and collector IP/port config, TLS certificate params has to be added under accounting service config and accounting service has to read the config and initiate a dial out connection which might be unnecessary.

[haussli]

It is now acctz.proto, but trying to address the questions:
1,2) it is not an ACK so much as it is a keepalive; that the client has not become brain-dead.

4,5) I expect that it is a ring-buffer of operator-configured size, with some reasonable default based on the platform (eg: backbone router size will not be the same as on a IoT device). Also, there may be more than one client and a client might lose connectivity but should not lose messages, so messages must persist rather than be client-specific.

6, 7) the idea of "push" has been removed.

[haussli]

I think that this is resolved and another can be opened if there are remaining questions.

[morrowc]

closing.