I am not sure I want failover to be handled at the IP transport level. Failover is something I would see as part of 'robust service connectivity' which would include what to do if one or both endpoint hosts failed. If I have a strategy for dealing with that I should get TCP reconnection for free. Part of the problem here, is I believe a misinterpretation of the OSI layer model, namely the idea that it is useful rather than a hinderance. Thinking in terms of layers introduces unhelpful political issues (lower layer folk think they are more important as they are the foundation for what is built on top, upper layer think the lower layers are beneath them). I now think of the 'layers' more as objects in an encapsulation/object oriented fashion. Where exactly does SSL fit in the layer model? It is actually an application layer protocol that presents what appears to be a transport protocol. And that is what I think any robustness package should look like. In fact I am pretty sure we have that already in the WS-* stack. I would make the same argument for multicast. Anything that I would want to use Internet multicast for is much better done by working at the application layer. Network multicast is another matter, there the deployment and security and resource allocation issues are tractable. Working at the application layer using unicast as my main protocol, I can imagine an architecture in which ISPs have the option of setting up application layer burst points that allow large volumes of data to be split off to multiple end recipients. As I am working at the application layer I can set up my communications so that I have a shared data channel and separate control/security channels for each endpoint (this could be a reasonably straightforward derrivative SSL even). I can also support caching at the nodes so that if 30% of the audience for the baseball streaming video are actually wanting to watch the game tape delayed, I can direct the data to be pulled from the cache at the burst point rather than send the data over the wire again. Such an architecture could present an upper layer that looks pretty much like HTTP as far as the application is concerned, just like SSL is pretty much like TCP/IP. But the main advantage of working that way, beyond simplicity is that instead of sitting on our thumbs waiting for multicast to become ubiquitous, we instead propose an architecture that creates direct incentives for parties to play nice. The broadband ISPs would have to pay for the cache hardware, their incentive to do so might be to reduce their connection costs and/or payments from content providers using the distribution mechanism. The content providers would have to write a bit of code to support the system but would also see their bandwidth costs drop. The most interesting part though, would be how the ISPs would select the content to cache. If there is a free market in broadband provision, then the interests of the ISPs will be to choose the content that minimizes their bandwidth costs. Otherwise they can attempt to charge, but content providers know that the alternative will cost the ISP money and reduce service to the customer, so their bargaining leverage is perhaps limited. A precondition for the scheme to work would be that the content would have to be signed and there would have to be accountability so the party injecting it into the system is a known entity. That is the sort of thing you can do at the application layer but does not make a whole lot of sense if you are dealling with the type of things you are allowed to be dealing with at the transport layer. Thats layers again... To the extent that the OSI model has utility, it is that there are objects that you can only interact with at particular layers in the stack. If it is copper wire then it better be layer 1, if it is IP addresses then layer X, if it is organizations then application layer. On Wed, Nov 4, 2009 at 10:27 PM, Christian Vogt <christian.vogt@xxxxxxxxxxxx> wrote: > > On Nov 5, 2009, Sam Hartman wrote: > >> There are a number of ways to do this, including hashing the six-tuple >> (five tuple plus flow ID) to choose an exit. > > Yes, this is an alternative to what is described in the paper I referred > to. It is an interesting idea actually. > >> None of this allows you to fail over a connection. > > Correct. Another question is whether session failover is a requirement. > This may depend on the type of network we look at. In some networks, > if failovers happen infrequently, a simple solution that causes some > sessions to break in the event of a failover may actually be acceptable. > > All this requires extra intelligence in applications, of course: for NAT > traversal, and potentially for automated session re-establishment. But > one may argue that applications require this functionality already > today. > > - Christian > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf