Re: [dtn-interest] Re: comparing protocols for reliability etc.

[Michael Demmer <[e-mail]>]

My instinct is that since we're going ahead with a definition for a  
hop-by-hop checksum only bundle authentication block, then we don't  
_need_ additional convergence-layer specific mechanisms for data  
integrity beyond what's provided by the lower transport layers.

This saves us the trouble (and potential errors) of defining and  
implementing specific checksum algorithms for each convergence layer.

-mike


>> I posted a few days ago amongst the turmoil of the recent paper
>> regarding data integrity.  Curiously, there have been no responses.
>> Hasn't anyone any comments?  If I'm very off plot, I'd hope someone
>> would put me straight.  Otherwise, I'm hoping someone might agree.
>
> Darren - you're not off plot. Many of us have travelled to the IETF  
> in Chicago, so the stuff related to in-the-room discussion has  
> taken precedence.
>
> IP fragmentation is unlikely because these convergence layers are  
> usually only supposed to travel one hop across a local link, and in  
> those scenarios they will know and use the local link MTU.  
> (Protecting against errors in lower layers segmenting and  
> reassembling packets is something I would be concerned about.)  For  
> a convergence layer that can traverse the public Internet - TCP has  
> Path MTU discovery to avoid fragmentation. Also, intermediate  
> fragmentation is avoided in the IPv6 design. Weakness of the one's- 
> complement checksum with large MTUs (especially jumbograms) is  
> another issue.
>
> We've spent a lot of time on the list discussing reliability to  
> catch residual errors - I certainly think that if a convergence  
> layer is advertised as "reliable" it should at least make an  
> attempt to catch all errors - and that's why we added the MD5  
> integrity checksum in Saratoga, to provide an attempt at an e2e  
> checksum to help applications that don't check what they receive.  
> This means that Saratoga can provide a better, more reliable UDP- 
> based convergence layer.
>
> The bundle protocol should imo always be reliable in both framing  
> and payload content, which it currently isn't - something there has  
> been much discussion of here in Chicago, post our payload checksum  
> block draft.
>
> L.
>
> http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/
>
> ===
> Hi all,
>
> I find this to be an interesting topic of discussion, and I can't
> help but chip in with some comments of my own.
>
> One possible concern that isn't addresses in the paper is the degree
> of error detection capability in the implemented CLs in the DTN2
> reference implementation.  I'm thinking specifically of the TCP and
> UDP CLs.
>
> In the UDP CL implementation, bundles are accepted for transmission
> up to the maximum UDP datagram size (64kB).  With typical link MTU
> sizes, this bundle/datagram would undergo IP fragmentation, which is
> apparently to be considered "very harmful" to data integrity in the
> "right" circumstances.
>
> Is it the intention to resort to bundle protocol extensions to handle
> the detection of residual errors above the CL, or should there be
> strong enough mechanisms in the CL itself?
>
> Similarly, the TCP CL implementation provides no additional error
> detection mechanisms above TCP itself, which suffers from the same
> check-summing weakness as UDP.  My concern with the TCP CL relates to
> TCP operation over routes bisected with TCP PEPs.  There are PILC
> documents that describe the potential impact of TCP PEPs to the
> end-to-end assumption of TCP, and coupling this with the additional
> potential for the PEPs to inject errors undetectable by the TCP/IP
> stack suggest to me that additional integrity checking should be
> provided in the CL, where I believe more efficient recovery options
> are available.
>
> I wonder what others think?
>
> Cheers,
>
> Darren
> _______________________________________________
> dtn-interest mailing list
> [e-mail]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest