There are several reasons that application designers might not use DCCP and SCTP, one is that they are not aware of them, others are that they may not understand the deployment consequences of doing so or may lack the necessary support infrastructure to do so.
Attitudes may also be somewhat colored by bad experience with multicast which offers a wealth of intelectual excercises but not a platform that layer 7 people are likely to be interested in building on. I don't even know whether multicast packets will arrive at my ISP.
I think that the point you make really is at the heart of what domain centric is all about. Part of what we are lacking are properly structured session and presentation layers. If you get those right it becomes much easier to make lower layer changes.
Take SCTP for example. It makes perfect sense to use SCTP as a transport layer for HTTP Web browsing. But to make that possible we have to have some basic infrastructure like how the Web browser can know when to use HTTP over SCTP transport. If the system is going to work at all this information must be delivered through the DNS, thats what its for.
For unreliable protocols such as DCCP and Multicast we need to have an archetype (strictly speaking the term is paradigm but that has been abused) in which the bulk channel over the unreliable medium is paired with a control channel managed via a reliable medium. This approach allows us to finesse the entire problem of multicast security - integrity is managed via the unicast control channel.
For example, say that we have a web service intended to serve some heavyweight supply chain integration task (integ). example.com might advertize support for SCIT as follows
_integ.example.com TXT "wspolicy=http://policy.exampl.com/integ.xml"
Where the URI points to some sixteen page detailed XML profile of the protocol implementation, credentials required, etc. etc.
If on the other hand we are connecting to the web server we might have the following:
www.example.com XPTR example.com
_http.example.com TXT "TCP SCTP"
_http._tcp.example.com TXT "minv=1.0 maxv=1.1 TLS=(root=SHA256:1e23hd47ft34...)"
_http._sctp.example.com TXT "minv=2.0 maxv=2.0 TLS=(root=SHA256:1e23hd47ft34...)"
_http._tcp.example.com SRV 1 1 80 "web1.example.com"
_http._tls_tcp.example.com SRV 1 1 443 "web2.example.com"
_http._sctp.example.com SRV 1 1 8000 "web3.example.com"
The first line simply makes www.example.com an alias for example.com
The second line declares the toplevel policy parameters for http
The third and fourth lines declare parameters for http over standard TCP and for SCTP
The last three lines are the SRV records for the three protocol variants (we assume that TLS upgrade takes place inband in HTTP/2.0.
The advantages to the protocol designer of this approach is that I can slot in a new transport protocol easily and I can make protocol changes that do not preserve backwards compatibility. HTTP/2.0 could use an incompatible binary transport designed for high speed rather than the traditional RFC822 approach. While we might debate the advantage of doing so for RFC822 it is pretty clear that the advantages for XML applications are real.
From: Lars Eggert [mailto:lars.eggert@xxxxxxxxx]
Sent: Mon 09/07/2007 1:53 AM
To: Tom.Petch
Cc: dcrocker@xxxxxxxx; ietf@xxxxxxxx
Subject: Re: Application knowledge of transport characteristics (was: Re:Domain Centric Administration)
On 2007-7-5, at 19:07, ext Tom.Petch wrote:
> If we had a range of transports (perhaps like OSI offered), we
> could choose the
> one most suited. We don't, we only have two, so it may become a
> choice of one
> with a hack. But then that limited choice may be the reason why
> the Internet
> Protocol Suite has become the suite of choice for most:-)
We have four standards-track transport protocols (UDP, TCP, DCCP and
SCTP), and, FWIW, SCTP has a concept of record boundaries.
Designers of applications and higher-layer protocols still have a
tendency to ignore SCTP and DCCP and the particular features they can
offer to applications. This can make applications more complex,
because they need to re-invent mechanisms that a more appropriate
transport protocol would have provided.
Lars
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf