Re: [tsv-area] [L.Wood@surrey.ac.uk: [dtn-interest] New bundle internet draft and paper comparing protocols forreliability errored delivery.]

Lloyd Wood <L.Wood@surrey.ac.uk> Wed, 25 July 2007 12:33 UTC

Return-path: <tsv-area-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDg3a-0007BR-D0; Wed, 25 Jul 2007 08:33:34 -0400
Received: from tsv-area by megatron.ietf.org with local (Exim 4.43) id 1IDg3Y-00078m-3C for tsv-area-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 08:33:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDg3U-00074V-7F for tsv-area@ietf.org; Wed, 25 Jul 2007 08:33:28 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDg3T-0006Sa-2m for tsv-area@ietf.org; Wed, 25 Jul 2007 08:33:28 -0400
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 25 Jul 2007 14:32:58 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAAAGLfpkaQ/uCKh2dsb2JhbACPZwEBAQgKJw
X-IronPort-AV: i="4.16,580,1175464800"; d="scan'208"; a="148960067:sNHT8606104518"
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6PCWu9M015413; Wed, 25 Jul 2007 14:32:56 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6PCWrkt002898; Wed, 25 Jul 2007 12:32:55 GMT
Received: from lwood-wxp01.cisco.com (che-vpn-cluster-1-152.cisco.com [10.86.240.152]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA15607; Wed, 25 Jul 2007 13:32:52 +0100 (BST)
Message-Id: <200707251232.NAA15607@cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 25 Jul 2007 13:32:21 +0100
To: weddy@grc.nasa.gov
From: Lloyd Wood <L.Wood@surrey.ac.uk>
Subject: Re: [tsv-area] [L.Wood@surrey.ac.uk: [dtn-interest] New bundle internet draft and paper comparing protocols forreliability errored delivery.]
In-Reply-To: <7.1.0.9.0.20070720171559.05d549e8@surrey.ac.uk>
References: <20070718033544.GD18544@grc.nasa.gov> <7.1.0.9.0.20070720171559.05d549e8@surrey.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Authentication-Results: ams-dkim-1; header.From=L.Wood@surrey.ac.uk; dkim=neutral
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: tsv-area@ietf.org
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Transport Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tsv-area>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
Errors-To: tsv-area-bounces@ietf.org

At Friday 20/07/2007 17:17 +0100, Lloyd Wood wrote:
>I should add that Saratoga, which uses UDP and UDP-Lite to deliver files and stream content, is described in
>http://www.ietf.org/internet-drafts/draft-wood-dtnrg-saratoga-01.txt
>
>We'll be presenting on this to tsv-area in Chicago.

Wes's slides yesterday are available with all other material describing Saratoga at:
http://www.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

fyi,

L.

>At Tuesday 17/07/2007 23:35 -0400, Wesley Eddy wrote:
>>The following announcement may be of interest to TSV-AREA in two contexts:
>>
>>a) We've been working with and analyzing protocols over UDP-Lite, which is
>>   a TSV product, and have tried to clearly spell out the support at other
>>   layers of the stack that's needed to get utility out of using UDP-Lite.
>>   Due to layering and tunneling of protocols that include checksums
>>   with different coverage, the effects are not always what's desired.
>>
>>b) Reliability and robustness are general transport topics, and Saratoga
>>   LTP, and DTN bundling have some approaches that are at least slightly
>>   different from existing IETF standards.  Saratoga's approach is heavily
>>   focused on the filling the requirements of specific pieces of content.
>>   The checksum we propose adding to DTN's bundle protocol also only
>>   covers the content (payload), and allows other fields to change in
>>   transit, which differs from psuedoheader use and transport header
>>   inclusion in typical Internet transport checksums.
>>
>>Here are quick links to the documents:
>>http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-wood-dtnrg-saratoga/wood-eddy-checksum-coverage-submitted.pdf
>>http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-eddy-dtnrg-checksum/draft-eddy-dtnrg-checksum-00a.txt
>>Lloyd's note below explains more in the context of ongoing DTNRG work.
>>
>>
>>----- Forwarded message from Lloyd Wood <L.Wood@surrey.ac.uk> -----
>>
>>To: dtn-interest@mailman.dtnrg.org
>>From: Lloyd Wood <L.Wood@surrey.ac.uk>
>>Subject: [dtn-interest] New bundle internet draft and paper comparing protocols forreliability errored delivery.
>>Date: Tue, 17 Jul 2007 21:35:54 +0100
>>
>>We have written up a paper examining reliability in protocols, and comparing four different transport protocols that offer delivery of errored data to applications. The insights gained in this work allow us to identify areas of the Licklider and bundle protocols where reliability suffers and more design work is needed. This paper fleshes out the ideas I expressed at the Dublin meet.
>>
>>http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-wood-dtnrg-saratoga/wood-eddy-checksum-coverage-submitted.pdf
>>Checksum Coverage and Delivery of Errored Content
>>Lloyd Wood, Wesley M. Eddy, Jim McKim and Will Ivancic
>>
>>Abstract -
>>   We examine how the overall reliability of network
>>   protocol stacks is affected by the use of error-detecting
>>   checksums and Cyclic Redundancy Checks at each protocol
>>   layer. How these checksums cover their frames and payloads can
>>   affect the reliability of the rest of the stack, particularly higher
>>   layers, and the resulting delivery of data. We then apply insights
>>   gained to a comparison of new protocols promising delivery of
>>   packets with payload errors, to determine how well those
>>   protocols achieve that goal when used in realistic stacks.
>>
>>The above paper has been submitted to ACM Computer Communications Review for review by the Review.
>>
>>
>>We have also done some work to address one of the areas of weakness that we have identified in that paper, by writing an internet-draft:
>>http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-eddy-dtnrg-checksum/draft-eddy-dtnrg-checksum-00a.txt
>>The DTN Bundle Protocol Payload Checksum Block
>>Wesley M. Eddy and Lloyd Wood.
>>
>>Abstract -
>>   The Delay-Tolerant-Networking Bundle Protocol includes a custody
>>   transfer mechanism to provide acknowledgements of receipt for
>>   particular bundles.  No checksum is included in the basic DTN Bundle
>>   Protocol, however, so it is not possible to verify that bundles have
>>   been either forwarded or passed through various convergence layers
>>   without errors having been introduced.  This document partially
>>   rectifies the situation by defining a Bundle Protocol extension for
>>   carrying payload checksums and describes how its use can be
>>   integrated with both custody transfer and fragmentation.
>>
>>This draft is currently pre-submission, as the drafts archive is not accepting submissions until after next week's IETF meet. Once the archive reopens, we will submit -00.
>>
>>Enjoy! See you in Chicago.
>>
>>L.
>>
>><http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk> 
>>_______________________________________________
>>dtn-interest mailing list
>>dtn-interest@mailman.dtnrg.org
>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
>>----- End forwarded message -----
>>
>>-- 
>>Wesley M. Eddy
>>Verizon Federal Network Systems