Re: [dtn] I-D Action: draft-burleigh-dtn-ecos-00.txt

["Burleigh, Scott C (US 312B)" <[e-mail]>]

Hi, Rick.  I think your objections are spot on.  The original ECOS design was an extension of the class-of-service setting in BPv6 and therefore an extension of the notion that the source application could be trusted to make wise decisions about how a bundle should be processed along its path to the final destination.  I think we are moving away from that notion and toward enabling forwarding nodes to make their own forwarding decisions, taking source applications' preferences into account as appropriate.

That is, I think we should start saying that the source application must be trusted to truthfully characterize its payload, but that the network nodes must then make their own forwarding decisions based on their assessments of the character of the payload in the context of current routing and resource demand considerations.

The way to apply this concept to the draft, I think, is to make it clear that everything in the ECOS (or "QOS"?) block is the source application's own processing preferences, but that all of these markings are strictly advisory: the extension block imposes nothing mandatory.

Does that sound right to you?

Scott

-----Original Message-----
From: dtn <[e-mail]> On Behalf Of Rick Taylor
Sent: Friday, May 7, 2021 8:55 AM
To: Templin (US), Fred L <[e-mail]>; [e-mail]
Subject: [EXTERNAL] Re: [dtn] I-D Action: draft-burleigh-dtn-ecos-00.txt

Hi Fred,

Firstly, thanks for publishing this draft, it's well written and I think it tackles some important use-cases.

Introducing a QoS block that allows marking of a bundle for particular treatment by agents along the path to the endpoint I think is generally accepted as a good idea.  As you state, the limited support in BPv6 was useful, and BPv7 was written with the understanding that a QoS extension block would follow.  I really like the "Numeric QoS Tag" concept that allows an administrative zone of control to decide the processing rules based on the tag value.

But this highlights the area I am not so sure about:  The "critical" flag places requirements on the forwarding function of the BPA, and I'm not sure that is a sensible idea.   I understand the need for a "Just Get It There!" flag, and yes, some kind of redundant multi-path forwarding could be a really effective way to do that, but in a late-bound delay tolerant network the source of a bundle is not likely to know that redundant broadcast from the next hop all the way to the destination is the best way to guarantee delivery of the critical bundle; in fact the flag as defined could be used as a very effective magnifying DDoS attack.  I would prefer to see the "critical" flag just describe the bundle as critical, and the draft can suggest that redundant forwarding might be a good mechanism if available, but the flag should not demand a certain forwarding strategy.

I also worry about the "Best Effort" flag for the same reasons: the text states the flag determines the selection of a Convergence Layer adaptor based on the characteristics of the CL - as with my concern with the 'critical' flag, I'm not keen on bundle content demanding specific forwarding strategy.  I also have a concern that not setting the "BE" flag could lull users into thinking that some kind of reliable forwarding will just happen automagically.

I won't repeat myself, but the same arguments as above could be made about applying BIBE.

I am also of the opinion that the "apply BSSP" (I think you mean BPSec these days) flag is probably better handled by the (undocumented) proposals for a Manifest Block that lists the blocks in a bundle, but there is not much detail on the BSSP flag.

In summary, I absolutely support a mechanism for a bundle to include  an extension that describes the characteristics of the bundle forwarding the sender would like used - but I firmly believe that the final arbiter of any bundle forwarding strategy must be the local bundle processing agent, governed by its local administrative policy.  I may decide that what you consider "critical" is only "best effort" as it transits my administrative area, but that should not prevent you from marking your bundles as "critical".

I really welcome this work, and getting the first draft written is an important milestone.

Sorry for the top-post.

Cheers,

Rick

> -----Original Message-----
> From: dtn [mailto:[e-mail]] On Behalf Of Templin (US), 
> Fred L
> Sent: 05 May 2021 21:46
> To: [e-mail]
> Subject: [dtn] FW: I-D Action: draft-burleigh-dtn-ecos-00.txt
> 
> Hello, see below for a -00 draft on "Bundle Protocol Extended Class of 
> Service (ECOS)".
> This is intended as an extension for BPv7 which starts with the 
> two-bit Priority values that were found in BPv6 to identify a Service 
> Class and extends them with an Ordinal Number to indicate the relative 
> priority within the class. Please review and provide comments on the 
> list.
> 
> Fred Templin
> 
> -----Original Message-----
> From: I-D-Announce [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: Wednesday, May 05, 2021 1:25 PM
> To: [e-mail]
> Subject: I-D Action: draft-burleigh-dtn-ecos-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : Bundle Protocol Extended Class of Service (ECOS)
>         Authors         : Scott Burleigh
>                           Fred Templin
> 	Filename        : draft-burleigh-dtn-ecos-00.txt
> 	Pages           : 9
> 	Date            : 2021-05-05
> 
> Abstract:
>    This document describes an extension to the Delay-Tolerant Networking
>    (DTN) Bundle Protocol (BP) that marks bundles with class-of-service
>    designators.  The class-of-service designators are an "ordinal"
>    number that provides fine-grained prioritization of bundles, a
>    "critical" flag, flags that explicitly request "timely" or "assured"
>    convergence-layer transmission (or both), and an optional QoS tag.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://urldefense.us/v3/__https://datatracker.ietf.org/doc/draft-burl
> eigh-dtn-ecos/__;!!PvBDto6Hs4WbVuu7!YE7Sx5oBPhVDcdhUlg7Dlw3JDgMr0T69-C
> 09CJqckd-kEiHTyqiAtf9zvlyTVvYBnCp1fQpYRFg$
> 
> There are also htmlized versions available at:
> https://urldefense.us/v3/__https://tools.ietf.org/html/draft-burleigh-
> dtn-ecos-00__;!!PvBDto6Hs4WbVuu7!YE7Sx5oBPhVDcdhUlg7Dlw3JDgMr0T69-C09C
> Jqckd-kEiHTyqiAtf9zvlyTVvYBnCp12nEgDuA$
> https://urldefense.us/v3/__https://datatracker.ietf.org/doc/html/draft
> -burleigh-dtn-ecos-00__;!!PvBDto6Hs4WbVuu7!YE7Sx5oBPhVDcdhUlg7Dlw3JDgM
> r0T69-C09CJqckd-kEiHTyqiAtf9zvlyTVvYBnCp1gJY2pGI$
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> https://urldefense.us/v3/__ftp://ftp.ietf.org/internet-drafts/__;!!PvB
> Dto6Hs4WbVuu7!YE7Sx5oBPhVDcdhUlg7Dlw3JDgMr0T69-C09CJqckd-kEiHTyqiAtf9z
> vlyTVvYBnCp1Ku0bPCc$
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://urldefense.us/v3/__https://www.ietf.org/mailman/listinfo/i-d-a
> nnounce__;!!PvBDto6Hs4WbVuu7!YE7Sx5oBPhVDcdhUlg7Dlw3JDgMr0T69-C09CJqck
> d-kEiHTyqiAtf9zvlyTVvYBnCp1ROES_Io$
> Internet-Draft directories: 
> https://urldefense.us/v3/__http://www.ietf.org/shadow.html__;!!PvBDto6
> Hs4WbVuu7!YE7Sx5oBPhVDcdhUlg7Dlw3JDgMr0T69-C09CJqckd-kEiHTyqiAtf9zvlyT
> VvYBnCp1kNxM31g$ or 
> https://urldefense.us/v3/__ftp://ftp.ietf.org/ietf/1shadow-sites.txt__
> ;!!PvBDto6Hs4WbVuu7!YE7Sx5oBPhVDcdhUlg7Dlw3JDgMr0T69-C09CJqckd-kEiHTyq
> iAtf9zvlyTVvYBnCp1rgAcxQ0$
> 
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://urldefense.us/v3/__https://www.ietf.org/mailman/listinfo/dtn__
> ;!!PvBDto6Hs4WbVuu7!YE7Sx5oBPhVDcdhUlg7Dlw3JDgMr0T69-C09CJqckd-kEiHTyq
> iAtf9zvlyTVvYBnCp1b9wQtsU$

_______________________________________________
dtn mailing list
[e-mail]
https://urldefense.us/v3/__https://www.ietf.org/mailman/listinfo/dtn__;!!PvBDto6Hs4WbVuu7!YE7Sx5oBPhVDcdhUlg7Dlw3JDgMr0T69-C09CJqckd-kEiHTyqiAtf9zvlyTVvYBnCp1b9wQtsU$