Re: [6lowapp] Charter and transports

Zach Shelby <zach@sensinode.com> Tue, 03 November 2009 20:35 UTC

Return-Path: <zach@sensinode.com>
X-Original-To: 6lowapp@core3.amsl.com
Delivered-To: 6lowapp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965CA3A69E8 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 12:35:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewoSXpseVrXf for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 12:35:12 -0800 (PST)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id EEE403A6807 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 12:35:11 -0800 (PST)
Received: from [192.168.1.5] (line-5076.dyn.kponet.fi [85.29.66.39]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nA3KZMFZ025587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Nov 2009 22:35:23 +0200
Mime-Version: 1.0 (Apple Message framework v1076)
Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes
From: Zach Shelby <zach@sensinode.com>
In-Reply-To: <01d401ca5c8f$2c7b5780$85720680$@sturek@att.net>
Date: Tue, 3 Nov 2009 22:35:25 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <18FFC87C-715D-4090-826C-353A066398BE@sensinode.com>
References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> <4AEF832C.9050603@eecs.berkeley.edu> <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> <66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com> <72876869-927E-45B6-A9D9-1A7E5A22E196@nokia.com> <EB72DA52-70E1-404B-A507-4871720A1FA8@archrock.com> <0D347129-430F-4902-B7AA-05D7B3360C2F@sensinode.com> <01d401ca5c8f$2c7b5780$85720680$@sturek@att.net>
To: <d.sturek@att.net>
X-Mailer: Apple Mail (2.1076)
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Charter and transports
X-BeenThere: 6lowapp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>, <mailto:6lowapp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowapp>
List-Post: <mailto:6lowapp@ietf.org>
List-Help: <mailto:6lowapp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>, <mailto:6lowapp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2009 20:35:13 -0000

On Nov 3, 2009, at 16:08 , Don Sturek wrote:

> I would like to see the issue of transport added to the charter.
>

Down below I suggested the text:

> "The protocol will operate over UDP by default, and should define an
> alternative binding to TCP or another suitable reliable transport
> layer."


Is that suitable for you? It allows for binding to future transports  
as well.

> For smart energy, we plan to start with TCP, hoping that our  
> relatively
> small networks and ROLL don't violate the TCP congestion control  
> timeout
> threshold and that the code size of TCP are not too much for our small
> devices.
>
> This said, we would like a back-up plan.  We need to have UDP as  
> that plan
> but not using TCP removes many of the interesting applications that  
> rely on
> TCP.
>
> I do think long term having transport in the charter for 6LowAPP/ 
> CoAp is a
> necessary thing.

We can't do real transport work (TCP improvements e.g.) in CoAP or the  
APP area as Lisa pointed out. The goal is however that this group (the  
6lowapp interest group in general) can spin off a new working group  
(or general activity) in the transport area for this purpose in the  
future. I think that makes sense. It would be best to first get some  
experience with CoAP and see where the real requirements and problems  
with TCP are.

Zach

>
> Don
>
>
> -----Original Message-----
> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On  
> Behalf
> Of Zach Shelby
> Sent: Monday, November 02, 2009 10:07 PM
> To: Jonathan Hui
> Cc: 6lowapp@ietf.org
> Subject: Re: [6lowapp] Charter and transports
>
> Hi,
>
> (New thread title)
>
> So to me the answer seems to be that TCP will work for some
> configurations, but obviously not for all networks, and not for all
> requirements (e.g. multicast).
>
> On Nov 3, 2009, at 5:15 , Jonathan Hui wrote:
>>
>>>> But are TCP's services/constraints
>>>> appropriate for the application?  I can think of a variety of LLN
>>>> applications that work just fine with TCP and others that could
>>>> stand
>>>> to use something else to improve latency, message efficiency, non
>>>> p2p
>>>> flows, multihoming, mobility,  etc.
>>>
>>> That's another question, yes. But I'd see building new transport
>>> layer functions for 6LOWAPPs as an activity that would need some
>>> very strong ties to the TSV area, if it wouldn't be hosted there in
>>> the first place.
>>
>> Agreed.  Though the line seems to be a bit blurred because some
>> suggest building transport-like mechanisms in whatever "app-level"
>> protocol we're working on.
>
> In the Stockholm BarBof, Lars had a very good explanation on this one.
> We very well may start TSV area work on transport improvements - but
> that is a long-term effort and won't happen in time for CoAP. I do
> think we should aim at starting that work eventually, but let's get
> CoAP started first.
>
> Obviously UDP is something we will need to support as a transport for
> CoAP, and I argue that we also need to allow the use of CoAP over TCP
> as this is useful for some applications. When using UDP, some simple
> mechanism for reliability (e.g. stop-and-wait) would of course be
> needed along with a transaction ID (see e.g. 6lowapp-frank-chopan).
> When doing this we should of course cooperate with TSV people.
>
> So this brings us to the next question, what should we say in the CoAP
> charter about transports? Right now it says
>
> "The protocol will operate over UDP...".
>
> I would suggest it says something more like:
>
> "The protocol will operate over UDP by default, and should define an
> alternative binding to TCP or another suitable reliable transport
> layer."
>
> What do you think?
>
> Zach
>
>>
>> --
>> Jonathan Hui
>>
>> _______________________________________________
>> 6lowapp mailing list
>> 6lowapp@ietf.org
>> https://www.ietf.org/mailman/listinfo/6lowapp
>
> -- 
> http://www.sensinode.com
> http://zachshelby.org - My blog "On the Internet of Things"
> Mobile: +358 40 7796297
>
> Zach Shelby
> Head of Research
> Sensinode Ltd.
> Kidekuja 2
> 88610 Vuokatti, FINLAND
>
> This e-mail and all attached material are confidential and may contain
> legally privileged information. If you are not the intended recipient,
> please contact the sender and delete the e-mail from your system
> without producing, distributing or retaining copies thereof.
>
>
>
> _______________________________________________
> 6lowapp mailing list
> 6lowapp@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowapp
>

-- 
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain  
legally privileged information. If you are not the intended recipient,  
please contact the sender and delete the e-mail from your system  
without producing, distributing or retaining copies thereof.