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

[Lloyd Wood <[e-mail]>]

At Thursday 26/07/2007 00:07 +0100, Darren Long wrote:
>Hi all,
>
>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