Clarity needed (in a comment) for acctz RecordRequest keepalives

[openconfig]

Clarity needed (in a comment) for acctz RecordRequest keepalives

[morrowc]

Oh, this is a good point. I believe in initial thoughts about this we had defined a keep-alive proto/packet... but were dissuaded from that path for reasons which aren't in my memory banks today :( I think minus the keepalive officially being a packet/message, you can certainly just heartbeat requests on a reasonable timer.

It seems likely that in some deployments you may go quite some time between 'changes' on devices, so your heartbeats may just not get returned data for long intervals of time. Decisions about: "is this connection dead? Is the far end overworked and can't reply, but still there??" seem like they get fixed at the TCP layer, mostly. It would be unfortunate if the client here decided after N no-replies to bounce the session, that is unnecessary work on the overall system, and possibly a confusing behavior :(

I think some thought/guidance on the system here is in order... I suspect that at least the idea that:

0. start session, ask for history be requested ("hi, give me everything since 27 days ago!")
1. delivery from server -> client of the backlog avaialble
2. sending of 'record request' with timestamp=record-received-timestamp
3. process replies if any are received
4. goto 2

is a good starting point, for me anyway, in the discussion.

[haussli]

OK, 2 suggests that it is not streaming; ie: that it sends stuff, waits for another request, sends stuff, repeat, while I previously thought that 2 was essentially ignored, like:

0. connect and send initial recordrequest (ie: RecordSubscribe)
1. wait for/receive msgs,
2. send keepalive if necessary
3. goto 1

[nmahabaleshwar]

I think in the current proposal there is no difference between a keep-alive and request message asking for records. At least the server treats every RecordRequest message as The client is asking something, let me check if I have something to be sent, it sends RecordResponses if there is any new event which happened after the timestamp in the message. It also uses this message as an indication that the client is still alive and consuming records. As @morrowc mentioned, some of the concerns about the liveness of the far-end can be handled by TCP so I am not sure if we need an application level keep-alive mechanism.

[haussli]

I disagree; its not clear to me.

The suggested semantics are "keep sending stuff as record sources post them, until a timeout or socket closure occurs".

Or, is it "send stuff, wait for a RRequest and send records from that timestamp, rinse repeat, until a timeout or socket closure occurs."

Or, is it some hybrid of those, such as "send stuff as record sources post them, when a RRequest arrives possibly backup to that date and begin sending records from there, until a timeout or socket closure occurs."

If TCP handles liveliness, then the entire timeout mechanism is unnecessary or maybe it can be defined based on the persistent inability to enqueue new records for sending. Still must define what happens if a RRequest arrives after the initial RecordSubscribe.

[nmahabaleshwar]

I think the current model is

Or, is it "send stuff, wait for a RRequest and send records from that timestamp, rinse repeat, until a timeout or socket closure occurs."

[haussli]

The comments from morrowc implied: "keep sending stuff as record sources post them, until a timeout or socket closure occurs".
I have no confidence that you or I know which is correct.

[morrowc]

It's almost certainly the case that I imagined this service in a totally incorrect manner :(
(this is probably where my original keep-alive type handling was supposed to be happening... that's since morphed)

Ok, so originally I viewed this as:

1. client connects to the server/device and asks for accounting records from at least time-X.
2. server/device sends all records in bunch (how that happens on the wire isn't important to me).
3. server/device keeps on sending new logs as they are created
4. the client was responsible to say periodically: "Still here!!" (keep-alive behavior)

Marcus, I think, dissuaded me from the keepalive method/thought process, effectively saying: "Hey, we have TCP keepalives, no worries!"

Now we believe/built a world where we are thinking the client will periodically tell the server/device: "Hey, since X more logs pls!"

I think that change is 'wrong thinking' on my part ;( If we agree on that (which would be awesome) then we just need to sort out expectations. I think the comment thread here says:

"Client connects, asks for history, Device streams records from history and then just sends records as the are created forever... if TCP timeouts happen go to the start"

That sounds, to me like the right thing, that a 'keep alive' application level function isn't necessary.

Now, how do we fix the documentation ? :)

[haussli]

I agree!
An implementation might also reset the session if the output queue remains full for too long (the "zero window" problem). That covers TCP remaining connect, but the remote being dead. also see ietf draft-chen-idr-tcp-user-timeout.

[nmahabaleshwar]

We are fine with this approach, can we close this issue ? We can raise a PR to update the documentation.

[haussli]

Please review #148 to address this behavioral change. TiA