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(_dot_)vogt(_at_)ericsson(_dot_)com> 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(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf