Subject: [Masque] HTTP Datagrams and Context ID registrations

From: Magnus Westerlund <[email-masked]>
Date: Tue, 13 Jul 2021 15:07:44 +0000

Hi,

I and my co-authors on
https://datatracker.ietf.org/doc/draft-kuehlewind-masque-connect-ip/ have
had some discussion around how one actually can and should be using the
context-ID registration mechanism. This as we are actually need it to
realize some of the functionality in our CONNECT-IP solution. 

We have found several ways that appear to practically work from an
CONNECT-IP application perspective. 

A.	Statically define that in the context of CONNECT-IP the application
will map certain formats to certain ContextID, and simply send registrations
without any extension headers. 
B.	Define a Context Extension that is intended to provide format
identifiers for the CONNECT-IP method different formats. 
C.	Use values or parameters in HTTP headers related to the format to
carry the identifiers.
D.	Combine A and B, so that we have a set of initially statically
defined mappings, and then use Context Extension for any future extensions. 

In our discussion we see that C appears to have some potential for failure
modes if an HTTP intermediary does things with the headers. 

A) is very straight forward for an application initially but can run into
trouble when needing to be extended but HTTP level negotiation of the
general functionality should resolve those. 

B) appears to have some overhead from an application perspective as each
application needs to define its own Context Extension to carry identifiers.
Is it really intended that each HTTP application that needs to convey some
identifier for its Context ID format to carry across the HTTP Datagram
capsule. Would there be a point in defining a Context Extension that carries
format identifier for what one like to use this context ID. 

D) appears to be simple initially, but leads to the extension mechanism
having code paths that would not be exercised by default

So this was basically to start a discussion to see if we can get a bit more
clearer guidance towards the HTTP application writers that will attempt to
use HTTP Datagram on how to actually use Context IDs. I noted that the
Connect-UDP method was no help as example yet.

I would also note that it appears that the current defined registration
method is great when one have three formats and need three different context
ID for the three different formats. It is not suitable if one end up in any
combinatorial cases, like formats that combine different modules where one
may suddenly have 128 potential different context IDs. Pre-registering all
of them appears to create a significant overhead. We had some thoughts of
actually carrying the DSCP + ECN values for an IP packet payload in the
Context ID. That could require up to 256 Context IDs. And registering each
value individually could be done, but ends up in a large number of
registrations, likely with a Context Extension TLV that consumes
additionally overhead. 

Cheers

Magnus Westerlund