Subject: [Anima] Magnus Westerlund's No Objection on draft-ietf-anima-grasp-api-08: (with COMMENT)

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Thu, 03 Dec 2020 06:21:26 -0800

Magnus Westerlund has entered the following ballot position for
draft-ietf-anima-grasp-api-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-grasp-api/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

So I didn't have time to read your document in detail, thus I can easily have
missed something.  Hopefully a bit of clarification on what I might have missed
will resolve this issue.

I do wonder over one aspect of this API surface. How does it handles when the
GRASP layer is unable to send the messages in a timely fashion based on the API
calls? Looking at GRASP I understand that it is using either UDP or TCP. The
rate limiting of UDP does not appear to be more well specified that to follow
RFC 8085 recommendations. So my concern here is that you actually have some
risk of running into that the upper layer using this API tries to become a bit
to active and do everything at once, thus resulting in that TCP congestion
control and flow control might block timely transmissions, and for UDP the rate
limiter / congestion control of the UDP messages. What happens in this API when
this occurs?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Dec 2020 09:07:11 +1300

Hi Magnus,

You raise an interesting point, but it's really about deployment
of the whole ANIMA infrastructure. We need the infrastructure to work
even when everything else is broken, which means it must have a
guaranteed slice of resource capacity and it should not exceed that
slice even when the autonomic system is fixing breakage.

If that doesn't work, GRASP sessions will start timing out, so the API
will report failures, starting with discovery failures**. That's where
the recommendation for exponential backoff comes in. But I think the
problem is deeper than the API.

** I've seen it happen, when running GRASP on a busy IETF wireless
network, back when we used to have meetings.

Regards
    Brian

Regards
   Brian Carpenter

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 4 Dec 2020 08:36:21 +0000

> problem is deeper than the API.

I raised this as I didn't see any discussion in the API that you could either
become hanging on a call waiting for local resources (which would be bad for
what I understand is intended to be asynchronous API) or how the calling APP
would learn that your request timed out, or simply are still being worked on
because busy. My concern is that without any type of push back towards the
calling application it can't regulate what it is doing to focuse the resources
on what is most important. Secondly, does there exist any prioritization
mechanism on the GRASP level that helps with this. 

Cheers

Magnus

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 5 Dec 2020 09:13:33 +1300

On 04-Dec-20 21:36, Magnus Westerlund wrote:
> what I understand is intended to be asynchronous API) 

GRASP itself would be the only source of a local wait, but it only consumes
standard resources (sockets and possibly o/s threads) so I don't see this
as a real issue.

> or how the calling APP
> would learn that your request timed out, 

That would come back as an error code, although the actual error code
would depend on the particular case. (In the case of discover(), it
just comes back as a blank reply.)

> or simply are still being worked on
> because busy. 

In a threaded implementation, the thread would simply sleep until
the error code pops up. In the event loop case, you'd get the
noReply code until something happens or the callback triggers.

> My concern is that without any type of push back towards the
> on what is most important.

I think it's going to be like the game loop in a complicated game.
It will have to pay attention to other issues while a negotiation
is proceeding. (Most of the times I used stackoverflow to figure
out how to do something in my own test cases, I found myself reading
advice to game implementers.)

> Secondly, does there exist any prioritization

No, we've never considered that. It wouldn't be hard to add
prioritization options to GRASP.

Thanks
   Brian

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 7 Dec 2020 09:58:15 +0000

Hi,

Thanks for the explanations. So if I interpret this from an API perspective, the
caller would make assumption that protocol messages will be sent in a timely
fashion that may not hold. Thus, timeouts that occurr might not be in relation
to the time since a message was sent. And the caller would not know about this
situation and would not throttle back its interactions. Given that GRASP is
implemented safely from a congestion and rate limiation it will not be
missbehaving, however the god put of the interaction might decrease due to this
lack of feedback. 

It is up to the authors and the WG I think what to do about this. I personally
think it might be worth creating a short section discussing this potential issue
so the API implementor might do something reasoanble. 

Cheers

Magnus

On Sat, 2020-12-05 at 09:13 +1300, Brian E Carpenter wrote:
> > > > Please refer to 
> > > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > I do wonder over one aspect of this API surface. How does it handles
> > > > when
> > > > the
> > > > GRASP layer is unable to send the messages in a timely fashion based on
> > > > the
> > > > API
> > > > risk of running into that the upper layer using this API tries to become
> > > > a
> > > > bit
> > > > control and flow control might block timely transmissions, and for UDP
> > > > the
> > > > rate
> > > > limiter / congestion control of the UDP messages. What happens in this
> > > > API
> > > > when
> > > > this occurs?
> > > > 
> > > > 
> > > > 
> > > >