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

"David R. Oran" <daveoran@orandom.net> Tue, 12 November 2019 14:03 UTC

Return-Path: <daveoran@orandom.net>
X-Original-To: coin@ietfa.amsl.com
Delivered-To: coin@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE19120033 for <coin@ietfa.amsl.com>; Tue, 12 Nov 2019 06:03:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tbbw5kkCUCkp for <coin@ietfa.amsl.com>; Tue, 12 Nov 2019 06:03:05 -0800 (PST)
Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C160E12002E for <coin@irtf.org>; Tue, 12 Nov 2019 06:03:05 -0800 (PST)
Received: from [24.60.31.220] ([IPv6:2601:184:407f:80ce:ca1:70bd:cbe4:d27a]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id xACE2rOS017874 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Nov 2019 06:02:55 -0800
From: "David R. Oran" <daveoran@orandom.net>
To: philip.eardley@bt.com
Cc: liupengyjy@outlook.com, coin@irtf.org
Date: Tue, 12 Nov 2019 09:02:47 -0500
X-Mailer: MailMate (1.13r5662)
Message-ID: <609D4356-A7D8-4EFB-8DE2-2C5A28437A74@orandom.net>
In-Reply-To: <LNXP123MB2587EABCC1F2ECD38373E378EB770@LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM>
References: <TYAPR06MB2318F351A7840A558D77C648DAF00@TYAPR06MB2318.apcprd06.prod.outlook.com> <LNXP123MB258736FB6E413F55C81BA122EB7F0@LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM> <PU1PR06MB2215BA135D7BD16A6AC523C5DA7A0@PU1PR06MB2215.apcprd06.prod.outlook.com> <LNXP123MB2587EABCC1F2ECD38373E378EB770@LNXP123MB2587.GBRP123.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_07382BDC-3F1D-4ADF-9B0D-37ED05BA4093_="; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/coin/3r6XhCrGkHJaM6hqx_6qnpMB8W4>
Subject: Re: [Coin] Draft-liu-coinrg-requirement-00 for discussion and comments
X-BeenThere: coin@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "COIN: Computing in the Network" <coin.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/coin>, <mailto:coin-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/coin/>
List-Post: <mailto:coin@irtf.org>
List-Help: <mailto:coin-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/coin>, <mailto:coin-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Nov 2019 14:03:08 -0000

On 12 Nov 2019, at 5:21, philip.eardley@bt.com wrote:

> 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.
>
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.

> Best wishes,
> phil
>
> From: 刘 鹏 <liupengyjy@outlook.com>
> Sent: 09 November 2019 07:52
> To: Eardley,PL,Philip,TUD1 R <philip.eardley@bt.com>om>; coin <coin@irtf.org>
> Subject: Re: RE: Draft-liu-coinrg-requirement-00 for discussion and comments
>
> 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
> ________________________________
> liupengyjy@outlook.com<mailto:liupengyjy@outlook.com>
>
> From: philip.eardley@bt.com<mailto:philip.eardley@bt.com>
> Date: 2019-11-05 01:45
> To: liupengyjy@outlook.com<mailto:liupengyjy@outlook.com>; coin@irtf.org<mailto:coin@irtf.org>
> Subject: RE: Draft-liu-coinrg-requirement-00 for discussion and comments
> 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 <coin-bounces@irtf.org<mailto:coin-bounces@irtf.org>> On Behalf Of liupengyjy@outlook.com<mailto:liupengyjy@outlook.com>
> Sent: 10 July 2019 15:48
> To: coin@irtf.org<mailto:coin@irtf.org>
> 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


> -- 
> Coin mailing list
> Coin@irtf.org
> https://www.irtf.org/mailman/listinfo/coin

DaveO