[e2e] end to end arguments in systems design -> checksums in bundle protocol
Kevin Fall
kfall at cs.berkeley.edu
Sat Dec 8 21:05:10 PST 2007
Well, I guess I should respond to the message from Lloyd regarding
checksums in the bundle protocol (DTNRG). As is not uncommon, I
believe he totally misrepresents what happened, for reasons I do not
(care to) know. The checksum was deliberately omitted. Here is why
(see www.dtnrg.org if you desire more background):
1. many of the environments we have discussed intend to run the
bundle protocol atop other protocols that already have checksums
2. there is a desire among some of the researchers to utilize object-
level reliability and security; requiring a checksum at the bundle
layer would be redundant
3. there is a security protocol (described separately) that provides
greater reliability than any simple checksum [yes, I do realize
various types of checksums or CRC-like codes can be used]
4. there is an extensibility mechanism in the bundle protocol, much
like IPv6 extension headers. If, remarkably, it is decided to put
one in the BP, it is a very simple matter
5. the BP is not necessarily a 'transport' protocol with transport
functionality in the Internet stack sense. There are discussions
regarding presentation-layer-like functionality
(indeed one might conceivably think of BP as a session protocol,
although we don't adopt "layerism" as any fundamental tenet)
I could go on, but those are the main reasons.
- K
On Dec 7, 2007, at Dec 712:00 PMPST, end2end-interest-
request at postel.org wrote:
>
>
>
> Today's Topics:
>
> 1. Re: end to end arguments in systems design (Lars Eggert)
> 2. Re: end to end arguments in systems design (Lloyd Wood)
> 3. Re: end to end arguments in systems design (David P. Reed)
> 4. Re: end to end arguments in systems design (Lars Eggert)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 6 Dec 2007 12:38:46 -0800
> From: Lars Eggert <lars.eggert at nokia.com>
> Subject: Re: [e2e] end to end arguments in systems design
> To: ext Lloyd Wood <L.Wood at surrey.ac.uk>
> Cc: Jon Crowcroft <Jon.Crowcroft at cl.cam.ac.uk>, e2e
> <end2end-interest at postel.org>
> Message-ID: <CD1B307C-C034-4BDB-8DDB-A739233FB8DE at nokia.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> Lloyd,
>
> On 2007-12-6, at 7:17, ext end2end-interest-bounces at postel.org wrote:
>> I've recently noticed that RFCs can get published without any
>> reference to how end-to-to-end reliability is ensured, even when
>> it's extremely relevant to the protocol being described and the
>> design decisions made for that protocol. This is not good -
>> particularly when detailing a new transport protocol or
>> entire architecture. Error detection and reliability can't just
>> be ignored.
>
> it sounds like you have a specific protocol/RFC in mind - can I ask
> which one?
>
> Lars
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 07 Dec 2007 03:14:37 +0000
> From: Lloyd Wood <L.Wood at surrey.ac.uk>
> Subject: Re: [e2e] end to end arguments in systems design
> To: Lars Eggert <lars.eggert at nokia.com>
> Cc: Jon Crowcroft <Jon.Crowcroft at cl.cam.ac.uk>, e2e
> <end2end-interest at postel.org>
> Message-ID: <200712070314.DAA02595 at cisco.com>
> Content-Type: text/plain; charset="us-ascii"
>
> At Thursday 06/12/2007 12:38 -0800, Lars Eggert wrote:
>> Lloyd,
>>
>> On 2007-12-6, at 7:17, ext end2end-interest-bounces at postel.org wrote:
>>> I've recently noticed that RFCs can get published without any
>>> reference to how end-to-to-end reliability is ensured, even when
>>> it's extremely relevant to the protocol being described and the
>>> design decisions made for that protocol. This is not good -
>>> particularly when detailing a new transport protocol or
>>> entire architecture. Error detection and reliability can't just
>>> be ignored.
>>
>> it sounds like you have a specific protocol/RFC in mind - can I ask
>> which one?
>
> Lars,
>
> Since you asked:
>
> Two examples that spring to mind are in the output of the IRTF
> Delay Tolerant Networking (DTN) research group - the DTN bundle
> protocol (now published as RFC5050) and the Licklider transport
> protocol (pending).
>
> Yes, these protocols are being published as IRTF experimental -
> which deliberately means 'anything goes' with good reason; no IETF
> review, to prevent limiting new ideas and approaches, nice big
> warning boilerplate at the top saying as much, caveat lector.
> (Though that boilerplate doesn't mention reliability as one example
> review criterion, it should imo, to encourage readers to bear
> reliability in mind. We take reliability of computers and
> transmission far too much for granted these days, and we shouldn't.
> All those IETFers beavering away on MacBooks which don't even have
> ECC RAM, not thinking about cosmic rays...)
>
> Still, one would expect any IRTF group to recognise reliability and
> error detection and handling as important (nay, fundamental! as is
> layering!) very early on in its initial design discussions...
>
> Once the lack of error detection in these DTN protocols was agreed
> to be an oversight, late in the design process after much lobbying
> and discussion, the DTNRG chairs made the call not to disrupt the
> then-ongoing publication process, rather than alter the protocol
> designs - having no error detection, or ways to ensure reliability,
> was seen by them as in retrospect a missing piece that needed to be
> added, but not considered that important a showstopping oversight
> or fundamental. [*]
>
> (The DTNRG group has been imo overly focused on security above all
> else, though lacking a threat analysis of any kind to work from,
> and attempts have since been made to add in reliability checks via
> reusing complex security mechanisms - which doesn't quite work for
> the bundle protocol. The interested can see all the caveats we laid
> out in the approaches in various drafts, including draft-irtf-dtnrg-
> bundle-checksum-00.txt, particularly in the security considerations
> at end. Reusing security protocols in this way also happily allows
> for more time to be spent on security protocol design, which is the
> raison d'etre of DTNRG. Still, at least the DTN's reliability
> problem is now under scrutiny, though rather late, and any kludged
> fix will be far less than ideal within the constraints of the
> published protocols.)
>
> This is just IRTF experimental stuff, likely just an interesting
> thought exercise worked out on paper, and nobody in their right
> mind would ever choose to deploy first-cut IRTF experimental
> protocols in real operational scenarios, right? But, should they do
> so, discovering errors and discussing what to do about them in the
> limits of the existing protocol designs and implementations could
> be grist for paper mills for years to come... who knows, the end-to-
> end principle and the reasons for it may even be rediscovered.
>
> Now, here's the chilling thought that Jon's email prompted: when
> the IRTF _itself_ clearly doesn't view the implications of the end-
> to-end principle and how you get stuff from A to B without
> detecting introduced errors as fundamentally important to bear in
> mind when doing initial designs in its research groups, and much
> effort has to be expended into getting reliability considered as an
> issue and accepted as worth looking at, "who cares?" wins, and we
> may as well close down the IRTF e2e mailing list as an obviously
> long-lost cause.
>
> Mandating an 'Implications for end-to-end reliability' section in
> drafts to encourage writers to think about reliability is a last
> line of defence. (Perhaps we should also have an 'Implications for
> layering' section, which might act as a useful bozo filter.) In
> many ways, we've already built the flaky network infrastructure
> that we so richly deserve, and focusing on security alone as a
> panacea can't fix that.
>
> If you wanted to see arguments about implications of basic end-to-
> end reliability on design in 2007,
> http://maillists.intel-research.net/pipermail/dtn-interest/
> was where it was at.
>
> Anyhow, seasons greetings and a happy new year to all and sundry.
>
> L.
>
> [*] to put it in perspective, it's rather like leaving checksums
> out of early UDP and TCP RFCs, and saying you'll fix it later. What
> could possibly go wrong?
>
> And since Jon prompted this and I've just been rereading his Dec
> '94 posting decrying ATM, which echoes down the years, it's
> tempting to simply say "J'Accuse, DTN."
>
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood at surrey.ac.uk>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 07 Dec 2007 00:42:03 -0500
> From: "David P. Reed" <dpreed at reed.com>
> Subject: Re: [e2e] end to end arguments in systems design
> To: Lloyd Wood <L.Wood at surrey.ac.uk>
> Cc: Jon Crowcroft <Jon.Crowcroft at cl.cam.ac.uk>, e2e
> <end2end-interest at postel.org>
> Message-ID: <4758DD2B.4010603 at reed.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Leaving such ideas as deciding where the reliability function is
> placed
> out of contemporary research seems silly - unless there is a really
> good
> reason for randomness.
>
> One can argue many views, but one must argue a particular view. It
> ain't obvious.
>
>
> Lloyd Wood wrote:
>> At Thursday 06/12/2007 12:38 -0800, Lars Eggert wrote:
>>
>>> Lloyd,
>>>
>>> On 2007-12-6, at 7:17, ext end2end-interest-bounces at postel.org
>>> wrote:
>>>
>>>> I've recently noticed that RFCs can get published without any
>>>> reference to how end-to-to-end reliability is ensured, even when
>>>> it's extremely relevant to the protocol being described and the
>>>> design decisions made for that protocol. This is not good -
>>>> particularly when detailing a new transport protocol or
>>>> entire architecture. Error detection and reliability can't just
>>>> be ignored.
>>>>
>>> it sounds like you have a specific protocol/RFC in mind - can I ask
>>> which one?
>>>
>>
>> Lars,
>>
>> Since you asked:
>>
>> Two examples that spring to mind are in the output of the IRTF
>> Delay Tolerant Networking (DTN) research group - the DTN bundle
>> protocol (now published as RFC5050) and the Licklider transport
>> protocol (pending).
>>
>> Yes, these protocols are being published as IRTF experimental -
>> which deliberately means 'anything goes' with good reason; no IETF
>> review, to prevent limiting new ideas and approaches, nice big
>> warning boilerplate at the top saying as much, caveat lector.
>> (Though that boilerplate doesn't mention reliability as one
>> example review criterion, it should imo, to encourage readers to
>> bear reliability in mind. We take reliability of computers and
>> transmission far too much for granted these days, and we
>> shouldn't. All those IETFers beavering away on MacBooks which
>> don't even have ECC RAM, not thinking about cosmic rays...)
>>
>> Still, one would expect any IRTF group to recognise reliability
>> and error detection and handling as important (nay, fundamental!
>> as is layering!) very early on in its initial design discussions...
>>
>> Once the lack of error detection in these DTN protocols was agreed
>> to be an oversight, late in the design process after much lobbying
>> and discussion, the DTNRG chairs made the call not to disrupt the
>> then-ongoing publication process, rather than alter the protocol
>> designs - having no error detection, or ways to ensure
>> reliability, was seen by them as in retrospect a missing piece
>> that needed to be added, but not considered that important a
>> showstopping oversight or fundamental. [*]
>>
>> (The DTNRG group has been imo overly focused on security above all
>> else, though lacking a threat analysis of any kind to work from,
>> and attempts have since been made to add in reliability checks via
>> reusing complex security mechanisms - which doesn't quite work for
>> the bundle protocol. The interested can see all the caveats we
>> laid out in the approaches in various drafts, including draft-irtf-
>> dtnrg-bundle-checksum-00.txt, particularly in the security
>> considerations at end. Reusing security protocols in this way also
>> happily allows for more time to be spent on security protocol
>> design, which is the raison d'etre of DTNRG. Still, at least the
>> DTN's reliability problem is now under scrutiny, though rather
>> late, and any kludged fix will be far less than ideal within the
>> constraints of the published protocols.)
>>
>> This is just IRTF experimental stuff, likely just an interesting
>> thought exercise worked out on paper, and nobody in their right
>> mind would ever choose to deploy first-cut IRTF experimental
>> protocols in real operational scenarios, right? But, should they
>> do so, discovering errors and discussing what to do about them in
>> the limits of the existing protocol designs and implementations
>> could be grist for paper mills for years to come... who knows, the
>> end-to-end principle and the reasons for it may even be rediscovered.
>>
>> Now, here's the chilling thought that Jon's email prompted: when
>> the IRTF _itself_ clearly doesn't view the implications of the end-
>> to-end principle and how you get stuff from A to B without
>> detecting introduced errors as fundamentally important to bear in
>> mind when doing initial designs in its research groups, and much
>> effort has to be expended into getting reliability considered as
>> an issue and accepted as worth looking at, "who cares?" wins, and
>> we may as well close down the IRTF e2e mailing list as an
>> obviously long-lost cause.
>>
>> Mandating an 'Implications for end-to-end reliability' section in
>> drafts to encourage writers to think about reliability is a last
>> line of defence. (Perhaps we should also have an 'Implications for
>> layering' section, which might act as a useful bozo filter.) In
>> many ways, we've already built the flaky network infrastructure
>> that we so richly deserve, and focusing on security alone as a
>> panacea can't fix that.
>>
>> If you wanted to see arguments about implications of basic end-to-
>> end reliability on design in 2007,
>> http://maillists.intel-research.net/pipermail/dtn-interest/
>> was where it was at.
>>
>> Anyhow, seasons greetings and a happy new year to all and sundry.
>>
>> L.
>>
>> [*] to put it in perspective, it's rather like leaving checksums
>> out of early UDP and TCP RFCs, and saying you'll fix it later.
>> What could possibly go wrong?
>>
>> And since Jon prompted this and I've just been rereading his Dec
>> '94 posting decrying ATM, which echoes down the years, it's
>> tempting to simply say "J'Accuse, DTN."
>>
>> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood at surrey.ac.uk>
>>
>>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 7 Dec 2007 11:21:10 -0800
> From: Lars Eggert <lars.eggert at nokia.com>
> Subject: Re: [e2e] end to end arguments in systems design
> To: ext Lloyd Wood <L.Wood at surrey.ac.uk>
> Cc: Jon Crowcroft <Jon.Crowcroft at cl.cam.ac.uk>, e2e
> <end2end-interest at postel.org>
> Message-ID: <103FAD02-401F-4ECB-BB2C-35D509E9372C at nokia.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> On 2007-12-6, at 19:14, ext Lloyd Wood wrote:
>> Two examples that spring to mind are in the output of the IRTF Delay
>> Tolerant Networking (DTN) research group - the DTN bundle protocol
>> (now published as RFC5050) and the Licklider transport protocol
>> (pending).
>>
>> Yes, these protocols are being published as IRTF experimental
>
> Thanks for clarifying. I was worried for a minute that you were
> referring to transport area standards track protocols.
>
> (And the rest of your email clarifies that you're concerned about the
> inner workings of DTNRG and what impact that has on their Experimental
> RFCs, and not on the workings of IETF WGs in this space. But shouldn't
> you bring this up on the DTNRG list, rather than that of a the E2E
> RG?)
>
> Lars
>
>
> ------------------------------
>
> _______________________________________________
> end2end-interest mailing list
> end2end-interest at postel.org
> http://mailman.postel.org/mailman/listinfo/end2end-interest
>
>
> End of end2end-interest Digest, Vol 46, Issue 2
> ***********************************************
>
More information about the end2end-interest
mailing list