Re: [Paw] Renaming

Lou Berger <lberger@labn.net> Thu, 04 April 2019 17:21 UTC

Return-Path: <lberger@labn.net>
X-Original-To: paw@ietfa.amsl.com
Delivered-To: paw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B3012009E for <paw@ietfa.amsl.com>; Thu, 4 Apr 2019 10:21:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 Ln_5ci_yO5aT for <paw@ietfa.amsl.com>; Thu, 4 Apr 2019 10:21:50 -0700 (PDT)
Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (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 BFE18120091 for <paw@ietf.org>; Thu, 4 Apr 2019 10:21:50 -0700 (PDT)
Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id BC411140572 for <paw@ietf.org>; Thu, 4 Apr 2019 10:51:11 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id C5a3h2tSFVLCbC5a3hXBKj; Thu, 04 Apr 2019 10:51:11 -0600
X-Authority-Reason: nr=8
X-Authority-Analysis: $(_cmae_reason
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=P9cxsA5uUFJGv7qrM8GrIwF0hJBUgEdit98JsojPn/A=; b=sqVYzy6ihgwjng9IklibtKj6BA q7rhBVhc5Ml1wDOzIxIez7Ju5o1/RDDdhSSJByO+JMObuYKwHxBFXzaHDBtOaWOAfH/5D3ehPdOn1 aiId1CZg+D7vbdaejdaB9E5O0;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:54274 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <lberger@labn.net>) id 1hC5a3-002JKX-AB; Thu, 04 Apr 2019 10:51:11 -0600
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "Venkatesan, Ganesh" <ganesh.venkatesan@intel.com>, "paw@ietf.org" <paw@ietf.org>, 'Juliusz Chroboczek' <jch@pps.univ-paris-diderot.fr>
References: <MN2PR11MB35656DBEDFAAA662DF39D339D8500@MN2PR11MB3565.namprd11.prod.outlook.com> <d086bbb4-7877-1931-9913-3bc6e01f21b0@labn.net> <311BE885E0DA8D4BB369A037CF5B64A7A0411A3C@ORSMSX107.amr.corp.intel.com> <MN2PR11MB3565EA5719916E0D47BA8CCCD8500@MN2PR11MB3565.namprd11.prod.outlook.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <66f55988-373a-e0dd-bdf1-b7a63a2bc347@labn.net>
Date: Thu, 04 Apr 2019 12:51:10 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <MN2PR11MB3565EA5719916E0D47BA8CCCD8500@MN2PR11MB3565.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 72.66.11.201
X-Source-L: No
X-Exim-ID: 1hC5a3-002JKX-AB
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:54274
X-Source-Auth: lberger@labn.net
X-Email-Count: 5
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/paw/N2XYUZ3Zd5SMT5uVyCogKZ8TYGM>
Subject: Re: [Paw] Renaming
X-BeenThere: paw@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: predictable and available wireless <paw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/paw>, <mailto:paw-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/paw/>
List-Post: <mailto:paw@ietf.org>
List-Help: <mailto:paw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/paw>, <mailto:paw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2019 17:21:53 -0000

Hi Pascal,

The core deliverables (3) and (4) are certainly much more centered on 
wireless (sub and cross) network specifics than I expected from a "DoW"  
perspective, so do agree that avoiding DetNet in at least the naming of 
this effort makes sense.

 > Do you think we nee to change it to address better you're a, b or c 
question?

 From you response, I think you're saying the planned work scope is 
perhaps closer to (d) i.e., something different.

Thanks,

Lou

On 4/4/2019 12:31 PM, Pascal Thubert (pthubert) wrote:
> I agree with that, that is mostly a), but sill would love to be able to express a multihop schedule possibly across technology.
> Which means that we need an abstraction at layer 3 where we can express timing offsets, things like that.
> 6TiSCH comes into play because from there we already have experience on multihop scheduling, even if the group itself did not work on it beyond the architecture.
> What the group would describe is complex path ala DetNet but with additional properties like overhearing, HARQ, and possibly constructive interference, for which we need to extend the detNet PREOF abstraction. Depending on the radio technology it could impose a time boundary to the transmission, or even dig into link selection which may abstract a radio channel or a beam.
> If you look at LPWAN, we provided generic methods like SCHC, and then there are radio specific documents that explain how this is translates on a particular radio, mostly by constraining to the subset of the generic model that is meaningful on that radio. I'd like to stick to that model of making sure that what we do is generic enough for a covered set of radios.
> I do not know if the charter will go as far as enable the group to produce c). It is not my priority but it does not seem that complicated either. If it does, I'd like to see the same for the other technologies, understanding that for the most part the scheduling is done under the cover so L3 can at bets provide hints to be defined, like a transmission deadline in absolute time.
>
> About the name, We cannot have Deterministic in it, even hidden in the DetNet abbreviation. "Deterministic" raises too much concern/discussion on the wireless piece. We has that discussion and concluded with SPAWN. RAW came later but I find it quite good so if there was a strong support from the group, I'd see no problem to swap. We'll also need to provide a definition of reliability and availability and as we discussed, 5nines is probably not the only or even best way to express any of that. Juliusz actually raised the point and I hope he continues on that path and even produces a spec for us.
>
> At the moment the proposed charter is like this:
> "
>
>
>      The group will:
>
>          1) Produce informational work describing deterministic wireless
>             use cases, in continuation to the DetNet Use Cases document
> 		
>           2) Produce informational work describing the technologies that the
>              group will cover (e.g., URLLC, TSCH, EHT and LDACS)
>
>          3) Produce a Standards Track document to define the generic data models
>             to install a SPAWN flow along a track providing packet replication,
>             elimination and ordering functions with spatial, frequency and time
>             diversity in a scheduled FD/TDMA wireless network.
>
>          4) Produce a Standards Track document to enable operations,
>             administration and maintenance (OAM) inside a SPAWN network, providing
>             packet loss evaluation and automated adaptation to enable trade-offs
>             between resilience and energy consumption.
>
>
> "
>
> Do you think we nee to change it to address better you're a, b or c question?
>
> All the best,
>
> Pascal
>
>> -----Original Message-----
>> From: Venkatesan, Ganesh <ganesh.venkatesan@intel.com>
>> Sent: jeudi 4 avril 2019 17:11
>> To: Lou Berger <lberger@labn.net>; Pascal Thubert (pthubert)
>> <pthubert@cisco.com>; paw@ietf.org
>> Subject: RE: [Paw] Renaming
>>
>> My understanding is that it is mostly (a) with some common
>> management/provisioning/control that you describe in (b). DoW would
>> probably be more apt for what our objectives are.
>>
>> Cheers --
>> ganesh
>>
>> -----Original Message-----
>> From: Paw <paw-bounces@ietf.org> On Behalf Of Lou Berger
>> Sent: Thursday, April 4, 2019 7:50 AM
>> To: Pascal Thubert (pthubert) <pthubert@cisco.com>; paw@ietf.org
>> Subject: Re: [Paw] Renaming
>>
>> Hi Pascal,
>>
>>       I think it's good to ensure the name is well aligned with the objectives of
>> the group/activity.  I left the BoF a little confused, is the scope of this work:
>>
>> (a) DetNet over any wireless technology using a layered (sub-)networking
>> model
>>       (i.e., each wireless network technology brings it's own
>>        management/provisioning/control plane)
>>
>> (b) DetNet over any wireless technology using an integrated (sub-)networking
>> model
>>       (i.e., the objective is a single integrated management/provisioning/control
>> plane
>>        for DetNet and different wireless network technologies)
>>
>> (c) A control(ler) plane for 6tisch
>>
>> (d) something else
>>
>> If (a) or (b), I see no reason to not use DetNet in the name so I like DoW
>> (Detnet over Wireless) or DfW (DetNet for Wireless)
>>
>> if (c) I'd include 6tisch in the name, maybe 6TC (6tisch Control)
>>
>> Lou
>>
>>
>> On 4/4/2019 3:39 AM, Pascal Thubert (pthubert) wrote:
>>> Dear all:
>>>
>>> Before we finalize our renaming, another alternate came up, RAW, for
>>> reliable available wireless.
>>>
>>> It's closer to PAW so it would be less of a surprise. I do not have a
>>> strong opinion. Since we already advertised SPAWN maybe it's better t
>>> stick to it.
>>>
>>> Opinions?
>>>
>>> Pascal
>>>
>>>
>> --
>> Paw mailing list
>> Paw@ietf.org
>> https://www.ietf.org/mailman/listinfo/paw