Subject: Re: [Coin] Draft-liu-coinrg-requirement-00 for discussion and comments

From: <[email-masked]>
Date: Mon, 4 Nov 2019 17:45:49 +0000

Peng,

Thanks for the draft, a few comments.

I agree with your target in Section 2.1 about integrating computing into the network.

Section 2.2 gives me the impression that COIN is all about great quality of service (deterministic, very low latency & packet loss).  I don't think COIN should be about developing new QoS techniques. As you hint at in the last paragraph of this section, if deterministic QoS is required then there are existing /emerging techniques for doing that, at least for networking resources (how about for computing resources?). I also think there are many COIN scenarios where it won't be critical to have low latency and packet loss rate.

Section 2.3 you mention the requirement for a network interface for the user to express their needs to the network. I agree that the interface between the "users" and the "COIN" is an important topic. Personally I don't think this is only about the user expressing their requirements - also the COIN expressing its capabilities (ie the resources it can offer), as I think this is important for making the system scale.

I think there are some very interesting requirements around the computing-networking overlap - for example, to allow joint optimisation over the (distributed) resources.

Best wishes,
Phil

From: Coin <[email-masked]> On Behalf Of [email-masked]
Sent: 10 July 2019 15:48
To: [email-masked]
Subject: [Coin] Draft-liu-coinrg-requirement-00 for discussion and comments

Dear all,

A new draft draft-liu-coinrg-requirement-00 was uploaded and available online https://datatracker.ietf.org/doc/draft-liu-coinrg-requirement/.

This draft points out the requirements including the new architecture, precision and intelligence of computing in network.

Comments are welcome!

Best regards,
Peng

---

From: 刘 鹏 <[email-masked]>
Date: Sat, 9 Nov 2019 07:51:43 +0000

Hi philip,

Thank you for comments.

I agree with you that not all scenarios require low latency and packet loss rate. There might be some basic applications just need some computing capabilities of network. What I thought about was that for new applications, there might be high requirements for the network, especially based on the new architecture of computing in the network. There are some existing techniques for deterministic latency and packet loss rate. But I am not sure if there would be some problems of adaptability in network computing.

Section 2.3 wanted to express exposing each other's requirements and capabilities of user and network , maybe it was a little terse.

For the joint optimisation over the distributed resources, I think it's a interesting topic, do you have any more ideas about it? More discussion is welcome!

Thanks again.

Regards,
Peng
________________________________
[email-masked]

From: [email-masked]<mailto:[email-masked]>
Date: 2019-11-05 01:45
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Draft-liu-coinrg-requirement-00 for discussion and comments
Peng,

Section 2.2 gives me the impression that COIN is all about great quality of service (deterministic, very low latency & packet loss).  I don’t think COIN should be about developing new QoS techniques. As you hint at in the last paragraph of this section, if deterministic QoS is required then there are existing /emerging techniques for doing that, at least for networking resources (how about for computing resources?). I also think there are many COIN scenarios where it won’t be critical to have low latency and packet loss rate.

Section 2.3 you mention the requirement for a network interface for the user to express their needs to the network. I agree that the interface between the “users” and the “COIN” is an important topic. Personally I don’t think this is only about the user expressing their requirements – also the COIN expressing its capabilities (ie the resources it can offer), as I think this is important for making the system scale.

I think there are some very interesting requirements around the computing-networking overlap – for example, to allow joint optimisation over the (distributed) resources.

Best wishes,
Phil

Dear all,

Comments are welcome!

Best regards,
Peng

---

From: <[email-masked]>
Date: Tue, 12 Nov 2019 10:21:44 +0000

Peng,

Can you explain a bit more about the problems with existing techniques for low /deterministic latency and packet loss? It would also be interesting to hear if there are specific issues of network computing that make the requirements more strict than for ‘ordinary’ applications.

I think it’s important to get the interface between the user & network correct.

The joint optimisation topic is discussed a bit in https://tools.ietf.org/html/draft-kutscher-coinrg-dir-01#section-5 – but I’m not sure how much we need to say in a requirements document.

Best wishes,
phil

From: 刘 鹏 <[email-masked]>
Sent: 09 November 2019 07:52
To: Eardley,PL,Philip,TUD1 R <[email-masked]>; coin <[email-masked]>
Subject: Re: RE: Draft-liu-coinrg-requirement-00 for discussion and comments

Hi philip,

Thank you for comments.

Thanks again.

Regards,
Peng
________________________________
[email-masked]<mailto:[email-masked]>

Best wishes,
Phil

From: Coin <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 10 July 2019 15:48
To: [email-masked]<mailto:[email-masked]>
Subject: [Coin] Draft-liu-coinrg-requirement-00 for discussion and comments

Dear all,

Comments are welcome!

Best regards,
Peng

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 12 Nov 2019 09:02:47 -0500

> Can you explain a bit more about the problems with existing techniques for low /deterministic latency and packet loss? It would also be interesting to hear if there are specific issues of network c…
They might in fact be less strict, since the involvement of the network devices in the actual computations means they can adapt better to variations or partial failures in the network paths. Applications running only in end hosts might have much longer recovery timers, inability to directly affect parallel paths or redundant execution sites, etc.

> I think it’s important to get the interface between the user & network correct.
Yes, and in fact the interface semantics might look quite different from what we see today for strictly end-to-end expressions of desired service. For example, with some careful thought applications might be able to directly express their required “tail latency probability”, to drive and EDF scheduler rather than a strict priority scheduler. the format is hard to do unless the system knows the execution characteristics of the application and not just the network marginal delay or loess probability.

> The joint optimisation topic is discussed a bit in https://tools.ietf.org/html/draft-kutscher-coinrg-dir-01#section-5 – but I’m not sure how much we need to say in a requirements document.
We may need to say a few things in terms of requirements if we want to consider “non-classic” semantics at the boundary between the application and the network, since doing joint optimization has implications for placement of computations driving routing rather than the reverse.

> -- 
> Coin mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/coin

DaveO