Re: [dtn] [EXT] RE: DTN scheme demux syntax

["Sipos, Brian J." <[e-mail]>]

Lucien,

Thanks again for all of these helpful details. I do agree that HTTP is under-appreciated as a stateless and timing-independent transport (timeouts are an application decision, not a protocol one).

Do you see a use for both query part (which has been more related to referenced object identity) and fragment part (which has been more related to the object content), or just the query part? And do you see any distinction between use of query part in bundle Source vs. Destination?

 

Keeping with the same conceptual use in HTTP and other protocols, I can see a use for pattern matching based on service path segments but not on query or fragment parts. Meaning a routing or endpoint configuration would match on the node-name and demux path but nothing further; though a receiving service would be able to see the full Destination EID, dissect the query, and potentially have conditional logic based on its content. The issue with pattern matching on query part is that there is no standard definition for normalizing the query (each scheme must define the syntax of the query part).

 

Also in keeping with the conceptual use of the fragment part, it’s possible to be present in the general URL but it is stripped off of what actually gets encoded on-the-wire. So while a general URI could have a fragment part, the EID that goes in the primary block or elsewhere would not have a fragment part (just like a browser strips off the fragment part when sending an HTTP request [1]).

 

The way this could be phrased in the ABNF definition would be as:

dtn-hier-part = "//" node-name name-delim demux [ "?" query ]

node-name = reg-name

demux = path-rootless / path-empty

 

which makes it more clear that the service demux *is* the path and not the suffix query part, which is just part of the EID.

 

The reason why I’m pushing for clarity here is that the URL/URI is something that browsers and HTTP had struggled with for a long time to get to the current state of protocol [1] and BCPs [2], and we can learn from their hard-won lessons rather than re-discover these kinds of edge situations after deployments are made.

 

[1] https://www.rfc-editor.org/rfc/rfc9110#section-4.2.5

[2] https://www.rfc-editor.org/rfc/rfc8820#section-2

 

From: Loiseau lucien <[e-mail]> 
Sent: Monday, December 12, 2022 6:27 PM
To: Sipos, Brian J. <[e-mail]>
Cc: Carlo Caini <[e-mail]>; [e-mail]
Subject: Re: [dtn] [EXT] RE: DTN scheme demux syntax

 


APL external email warning: Verify sender [e-mail] <mailto:[e-mail]>  before clicking links or attachments

 

Hi Brian,

 

It is my intuition that the bpv7 protocol could be very valuable as an "overlay" of HTTP to transparently deal with intermittent connectivity as it is often the case with mobile development. At least it is how we are using it.

Indeed, our mobile app logic depends on some services from our backend. Typically those services would be served over HTTP apis. However in our case we expose those service over BP EID. As such, from the mobile side instead of doing an HTTP query to the targeted URL endpoint to query the http service, we instead send a Bundle to an endpoint whose URI is almost exactly a 1:1 mapping of the targeted URL, the only difference being the scheme part. For instance https://ourdomain/service/v1/cmd would become dtn://ourdomain/service/v1/cmd. On the backend side, we would have a microservice that awaits for incoming bundle over such EID. 

 

We do still rely on HTTP but only as a convergence layer to relay pending bundles on either side. As such, we expose a URL https://dtn.ourdomain/gateway  whose only purpose is to receive and send pending bundle within a single HTTP query. (we have design our own CLA for that purpose but it is extremely simple, basically the body of the query is used to serialize bundles flowing from mobile to backend, and the body of the http response is used to serialize bundles from the backend to the mobile device). Effectively, we are tunnelling DTN over HTTP.

 

We actually like this approach a lot for multiple reasons:

- from an architecture point of view it is extremely similar to HTTP and so easy to port the code of various endpoints and handlers from being an HTTP service to be a DTN service

- it allows the mobile side to also work as a "server" also. Indeed, without DTN, the backend wouldn't be able to easily "query" the mobile for some service. This is because a connection is always initiated by he mobile for various reason (mobile is not always within cellular range, wireless interface may be off, application may not be in foreground, mobile OS kill background services). However each successful http query relaying bundle on both side, and since the address space is flat and there is no "NAT", we can simply send a Bundle from the backend side to an EID belonging to the mobile and it will get routed through. The software on the mobile side is periodically polling HTTP to make sure that bundles are flowing.

- it is actually cleaner because mobile development is de-facto asynchronous driven and DTN fits this model better than HTTP. We don't need to retry failed API request nor deal with retransmission and such, this is all taken care of by the BP.

 

As such, I believe there is great value in having bundle protocol EID naturally mapping to HTTP URL as it makes 1:1 relationship trivial and enables a great use case for DTN. This is how we are currently leveraging this protocol.

 

Kind Regards,

Lucien

 

On Mon, Dec 12, 2022 at 11:42 PM Sipos, Brian J. <[e-mail] <mailto:[e-mail]> > wrote:

Carlo and Lucien,

Thank you for the feedback! I was searching for whether this was a theoretical or practical use and your experiences are very valuable. I still think that the query and fragment portions of the URI are overly complicated and unnecessary from the perspective of naming and pattern matching. Especially since path segments can themselves have parameters, if such a thing is needed.

 

From: Loiseau lucien < <mailto:[e-mail]> [e-mail]> 
Sent: Monday, December 12, 2022 3:20 PM
To: Scott Burleigh < <mailto:[e-mail]> [e-mail]>
Cc: Sipos, Brian J. < <mailto:[e-mail]> [e-mail]>;  <mailto:[e-mail]> [e-mail]
Subject: Re: [dtn] [EXT] RE: DTN scheme demux syntax

 


APL external email warning: Verify sender [e-mail] <mailto:[e-mail]>  before clicking links or attachments

 

Hi Brian,

 

In our modest use of BP, our EID structure is quite similar to that of how one would structure a restful api in HTTP. We have an application agent named "MuxAgent" that lets the application logic registers EID paths with associated handlers such as:


MuxAgent(base-eid = "dtn://mynodeid/")
   .handle("/service/v1/cmd1",  cmd1)
   .handle("/service/v1/cmd2",  cmd2)
   .handle("/service/v1/cmd3",  cmd3)

For each call to handle, the MuxAgent registers the Bundle Node as a member of the EID made of the base-eid and the path ("dtn://mynodeid/service/v1/cmd1", "dtn://mynodeid/service/v1/cmd2", etc.)
The MuxAgent then route received ADU to the appropriate handler. 


Lucien

 

 

On Mon, Dec 12, 2022 at 9:05 PM Scott Burleigh <[e-mail] <mailto:[e-mail]> > wrote:

Brian, thanks, an interesting idea.  My inclination would be to say that this sort of mechanism would be fine for the "dtn" URI scheme, but I wouldn't want to extend the "ipn" scheme in this sort of way: the whole point of that scheme is to enable predictably terse bundle blocks, to support communication over constrained links, and this sort of extensibility would defeat that purpose.

 

What I *do* think could make sense would be a machine-readable catalogue of service numbers that could associate arbitrarily lengthy and informative strings with service numbers.  I think that indirection might enable the sort of behavior you're thinking about.

 

Scott

 

On Mon, Dec 12, 2022 at 8:56 AM Sipos, Brian J. <[e-mail] <mailto:[e-mail]> > wrote:

Scott,

Is there any precedence for having multi-segment service names (like “some/long/path”) in ION or otherwise?

I am wondering if there is some benefit for allowing multi-segment names or if it is more simple, and more in alignment with non-hierarchical IPN service naming, for a service to have a single-segment name?

 

My original reason for looking into this is for EID pattern matching, where multi-segment patterns get significantly more complex than single-segment. Is there any implied expectation that an endpoint would be able to register a subtree of service names, like an endpoint that handles “some/*” to be able to receive for “some/thing” and “some/other” etc.? Even this seems excessive without a specific use case.

 

Thanks for your thoughts,

Brian S.

 

From: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> > 
Sent: Friday, December 9, 2022 12:24 PM
To: Sipos, Brian J. <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Subject: [EXT] RE: DTN scheme demux syntax

 


APL external email warning: Verify sender [e-mail] <mailto:[e-mail]>  before clicking links or attachments

 

Brian, good point; this certainly looks like a candidate for an erratum.  Aligning with path-rootless makes more sense to me, just because – as you say – it would be unwieldy for a node to have to register in every endpoint formed in this scheme, including every query.

 

Scott

 

From: Sipos, Brian J. <[e-mail] <mailto:[e-mail]> > 
Sent: Friday, December 9, 2022 8:09 AM
To: [e-mail] <mailto:[e-mail]> 
Cc: [e-mail] <mailto:[e-mail]> 
Subject: DTN scheme demux syntax

 

All,

While investigating a method of pattern matching for EIDs I ran into what may be a slight oversight in the DTN scheme definition. Currently the service portion of the URI [1] is defined as “demux = *VCHAR” which is any visible ASCII character. This is slightly different than the generic URI syntax with path-segment definition [2] as “segment = *pchar” which allows only unreserved (or percent encoded) characters, or even the “path-rootless” definition that would exclude query and fragment parts. The difference is in whether the DTN scheme demux allows an entire structured path (with potentially a query and fragment as well) or whether it is restricted to just one path segment.

 

Certainly the DTN scheme allows EIDs that look like:

dtn://node-name/service

dtn://other.node/tunnel

dtn://other.node/srv;with=parameter

 

But these are also currently allowed:

dtn://node-name/some/long/path

dtn://other.node/service?with=query#and-fragment

 

There’s no mention on how a BPA or an endpoint is supposed to actually deal with these kind of EIDs, meaning each query and each fragment ID would need to be registered as a different endpoint. Also keep in mind that while there may be purpose-built EID parsers within a BPA, these are still URIs and will inevitably be handled by non-dtn-aware tools that just know how to manipulate URIs following the generic syntax.

Does the DTN scheme make sense in this regime, or would it be better to consider this as an errata and restrict the DTN service demux to a single path segment? The comment in [1] actually says “path-rootless” but the ABNF matches more than just that.

Thanks,

Brian S.

 

[1] https://www.rfc-editor.org/rfc/rfc9171.html#section-4.2.5.1.1

[2] https://www.rfc-editor.org/rfc/rfc3986#section-3.3

 

_______________________________________________
dtn mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/dtn




 

-- 

--
Lucien Loiseau




 

-- 

--
Lucien Loiseau