Subject: [Netconf] Netconf notifications and transport flow control?

From: Erik Nordmark <[email-masked]>
Date: Fri, 23 Aug 2013 19:19:41 -0700

I was looking at RFC 5277 to see what would happen if a client 
subscribes to netconf events, there are lots of events generated, and 
the client is slow at receiving those events. That would result in the 
transport (e.g., ssh) being flow controlled.

The document looks silent on this topic.

In the extreme the netconf server might run out of memory if it needs to 
queue all the events for arbitrarily slow clients. Should the server 
rudely close the transport connection when this happens?
Or should the netconf server (silently) drop events if the client is 
slow at receiving them?
Or is there a mechanism by which the server can tell the client "I've 
dropped N events since you were too slow"?

RTFM's welcome.

Thanks,
    Erik

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 28 Aug 2013 10:39:49 +0200

Could some of the implemetors respond to this question please?

Bert

On 8/24/13 4:19 AM, Erik Nordmark wrote:
>
> I was looking at RFC 5277 to see what would happen if a client subscribes to netconf events, there are lots of events generated, and
> the client is slow at receiving those events. That would result in the transport (e.g., ssh) being flow controlled.
>
> In the extreme the netconf server might run out of memory if it needs to queue all the events for arbitrarily slow clients. Should
> the server rudely close the transport connection when this happens?
> Or should the netconf server (silently) drop events if the client is slow at receiving them?
> Or is there a mechanism by which the server can tell the client "I've dropped N events since you were too slow"?
>
> RTFM's welcome.
>
> Thanks,
>     Erik
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 28 Aug 2013 10:47:48 +0200 (CEST)

Hi,

"Bert Wijnen (IETF)" <[email-masked]> wrote:
> > I was looking at RFC 5277 to see what would happen if a client subscribes to
> > netconf events, there are lots of events generated, and

Correct.  Which means that this is currently no standard behavior in
this case, and thus up to the implementations to decide what to do.

/martin

> > queue all the events for arbitrarily slow clients. Should

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 28 Aug 2013 07:36:16 -0700

> this case, and thus up to the implementations to decide what to do.

Thanks Martin.

Do you (or the list) know what the range of implementation choices that 
are out there?

The ones I could come up with (silently not send some events, or drop 
the transport connection) seems a bit surprising and disruptive.

    Erik

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 28 Aug 2013 16:49:51 +0200 (CEST)

Erik Nordmark <[email-masked]> wrote:
> Do you (or the list) know what the range of implementation choices that are out
> there?
> 
> The ones I could come up with (silently not send some events, or drop the
> transport connection) seems a bit surprising and disruptive.

Assuming a stream with replay, dropping the transport might actually
not be that disruptive - since in this case the client can reconnect
and ask for a replay of the notifs that has occured since the last
successfully received one.

Silently dropping notifs is no different than whar would happen with a
UDP-based solution like SNMP or syslog (over UDP).

The problem should be similar for SNMP or syslog over TCP (over
something); it seems neither RFC 6587, RFC 6353, nor RFC 5592 mention
this problem, but I may have missed it.

/martin

> >>> Or should the netconf server (silently) drop events if the client is slow
> >>> at
> >>> receiving them?

---

From: Michal 'vorner' Vaner <[email-masked]>
Date: Wed, 28 Aug 2013 17:00:24 +0200

Hello

> the transport connection) seems a bit surprising and disruptive.

From a common sense point of view, I'd be very afraid of silently dropping,
since the receiving entity thinks everything is OK. Closing connection is not
optimal, but the other side at least knows there's a problem and someone will
get prompted to investigate.

With regard

-- 
  I'm a dragon, and I will not be ignored, not even by a tree!
       Saphira Brightscales

Michal 'vorner' Vaner

---

From: Andy Bierman <[email-masked]>
Date: Wed, 28 Aug 2013 08:07:03 -0700

>> Do you (or the list) know what the range of implementation choices that are out

One implementation strategy is to use a shared ring buffer for events.
If a notification is not delivered to a particular client before the ring buffer
wraps (to that event), then that client will lose that event. IMO dropping
the session because of a missed event is too disruptive.

This is why I added a <sequence-id> element to <notification>, but it is
disabled by default because the XSD does not allow extra nodes.

We also added a <cancel-subscription> operation.
Not sure why the RFC does not have it, but killing
the session and starting a new one in order to change
notification delivery seems extreme.

> this problem, but I may have missed it.

Andy