Re: [6lowapp] Charter and transports

Lloyd Wood <L.Wood@surrey.ac.uk> Tue, 03 November 2009 17:26 UTC

Return-Path: <L.Wood@surrey.ac.uk>
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 B7FA328C118 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 09:26:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 6i0ZHG2zvj41 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 09:26:26 -0800 (PST)
Received: from mail80.messagelabs.com (mail80.messagelabs.com [195.245.230.163]) by core3.amsl.com (Postfix) with SMTP id 55CD728C114 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 09:26:25 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: L.Wood@surrey.ac.uk
X-Msg-Ref: server-5.tower-80.messagelabs.com!1257269205!74997955!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [131.227.102.140]
Received: (qmail 21870 invoked from network); 3 Nov 2009 17:26:45 -0000
Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-5.tower-80.messagelabs.com with SMTP; 3 Nov 2009 17:26:45 -0000
Received: from ads31.surrey.ac.uk ([131.227.120.131]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 17:26:43 +0000
Received: from [192.168.1.209] ([86.3.114.249]) by ads31.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 17:26:43 +0000
Message-Id: <0562912A-A163-4938-9146-6E6DC6D2B316@surrey.ac.uk>
From: Lloyd Wood <L.Wood@surrey.ac.uk>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D8E01DD@XMB-AMS-107.cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 3 Nov 2009 17:26:42 +0000
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><921972845143124766@unknownmsgid><ca722a9e0911030839s7d2f609bu2e4adaa02298c66e@mail.gmail.com> <261EF2B6-82AF-4FBD-AC71-609617E7A7CE@surrey.ac.uk> <6A2A459175DABE4BB11DE2026AA50A5D8E01DD@XMB-AMS-107.cisco.com>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 03 Nov 2009 17:26:43.0585 (UTC) FILETIME=[CFE94F10:01CA5CAA]
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 17:26:27 -0000

On 3 Nov 2009, at 17:09, Pascal Thubert (pthubert) wrote:

> Hi Lloyd,
>
> Glad you mention it.
>
> Is there a way to see Saratoga without the 'DTN' piece?

The DTNRG bundle support is specified in a separate DTNRG draft, which  
can
be ignored entirely, along with the single bit saying 'carrying  
bundles'.
That's unimportant.

http://tools.ietf.org/html/draft-wood-tsvwg-saratoga
specifies only Saratoga and how it does file delivery and streaming.

(As an aside, I'm not convinced by the utility of DTN bundling;
doing HTTP over a variety of transports including TCP to make
it useful for unusual environments seems promising, though.)


> Could you elaborate a bit on how flow control is done in Saratoga?

If you mean congestion sensitivity, it's entirely open.
There's sufficient information flowing between sender
and receiver for a variety of schemes to be implemented, as
http://tools.ietf.org/html/draft-wood-tsvwg-saratoga
mentions - LEDBAT, TCP friendliness, etc. Pick a scheme
that suits; in many private dedicated links where link
utilization is a concern, and losses are due to channel
errors and not congestion, one might choose to run at link rate
for fast transfers.

Otherwise - HOLESTOFILL packets are sent by the receiver
or requested by the sender, and include necessary selective
negative acknowledgement (SNACK) information for reliable
file transfer or reliable streaming.

L.

>
> Cheers,
>
> Pascal
>
>> -----Original Message-----
>> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On
> Behalf Of Lloyd Wood
>> Sent: mardi 3 novembre 2009 17:57
>> To: 6lowapp@ietf.org
>> Subject: Re: [6lowapp] Charter and transports
>>
>>> 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.
>>
>> http://tools.ietf.org/html/draft-wood-tsvwg-saratoga
>>
>> is such a protocol, providing reliability and IDs.
>>
>> L.
>>
>> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>>
>> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk>