RE: shim - transport/app communication

["Bound, Jim" <jim.bound@hp.com>]

This is sooooooooo true.  In 90% of the cases the way this plays out in
industry is the apps require to be ported to use the new feature.  For
access to the IP stack most new APIs today can do it in AF and Transport
friendly manner but that requires an initial port.  

/jim 

> -----Original Message-----
> From: Dirk Henrici [mailto:henrici@informatik.uni-kl.de] 
> Sent: Wednesday, March 23, 2005 5:33 AM
> To: fred@cisco.com; iljitsch@muada.com; Bound, Jim; shim6@psg.com
> Subject: Re: shim - transport/app communication
> 
> It seems that the same problems are talked about in many discussions, 
> not only in this list:
> 
> Today
> - apps need to be aware of addresses
> - apps are bound to certain transport protocols at design 
> time, in fact
>    UDP and TCP
> 
> This makes introducing new protocols (e.g. IPv6, SCTP) a very 
> hard task.
> 
> 
> Baker Fred wrote:
> > On Mar 16, 2005, at 2:31 AM, Jeroen Massar wrote:
> >> the only thing an application should depend on here is that it 
> >> supports IPv6 addresses
> > 
> > 
> > If I could make a humble request here...
> > 
> > Could we please manage to avoid the worst of the layering faults we 
> > committed in the IPv4 Internet? The thing that has made NAT 
> hard and 
> > made applications break crossing a NAT was that the 
> applications know 
> > something about addresses. Let's not do that with IPv6 applications.
> > 
> > Applications should know about names and APIs, period. They 
> should open 
> > a socket-or-whatever to a name, and accept that the service 
> underneath 
> > gets them to an instantiation of it.
> 
> Iljitsch van Beijnum wrote:
>  > The only real solution that I can see here is yet another API that
>  > moves address resolution out of the application, and 
> completely hides 
>  > the IP version from the application.
> 
> Bound, Jim wrote:
>  > Something different.  Map an TCP request to an SCTP 
> request as if the
>  > transport selected was SCTP.
> 
> 
> I think that introducing a layer that maps TCP requests to 
> SCTP requests 
> is no more than a short term solution. It is time to solve the REAL 
> problem: that applications are aware of the network layer and the 
> transport layer.
> 
> I agree with Iljitsch and the others that another API as a long term 
> alternative to the "good old" socket API is needed.
> 
> This API should be crafted in such a way that protocols at the 
> network/transport layer can be changed transparently without 
> affecting 
> applications any more.
> To enable this, applications should specify which "services" 
> they need 
> (e.g. bidirectional reliable messages, low delay) and a new layer 
> between applications and transport layer selects and uses the most 
> appropriate protocols available with which the desired destination is 
> reachable.
> 
> Of course, this is off-topic in this working group here. But a newly 
> created working group could address the topic. What do you 
> think about that?
> A collegue of mine is doing his PhD on that topic. I'm sure he could 
> provide a lot of input...
> 
> 
>    Dirk
> 
>