[RRG] Practicality of upgrading hosts

[Robin Whittle <rw@firstpr.com.au>]

Tony Li wrote in "Re: [RRG] A new draft about Hierarchical Routing
Architecture":

> Alternately, it's pretty clear that we're getting to the point
> where OS release updates are getting to be pretty well automated.
> We can certainly expect that as we get large-scale experience with
> v6, we will find bugs with it, that those bugs will get addressed
> in service packs or similar updates.  It would seem that host
> vendors could also use the same mechanism to make changes to the
> host stack using their automated release process.

> So, IMHO, changes to the host stack are still extremely viable.
> It's true that they won't get overnight deployment, but then the
> router world is no longer deploying new code nightly either.


A subset of desktop and server machines might be affected by
upgrades to their operating systems.  However, many are not, and
there are other devices in the Net which are not practical to
upgrade at all.   I understand that many home users don't regularly
update their OS and applications - I don't do it as much as I
should.  Likewise, I understand that in corporate settings there is
wariness about updates, which might introduce bugs and new
vulnerabilities - but a worse threat of the same if updates are not
done.


I think a requirement for new host functionality is only useful for
a new architecture (except perhaps as part of a very long-term plan)
as long as:

1 - The new host functionality helps the user of that
    machine, without requiring the correspondent host
    to be upgraded.  (This is the basic "why would an
    early adopter bother to invest in an upgrade"
    problem, except that perhaps it requires the OS
    authors to make the investment, and many host users
    wouldn't face any costs at all.)

    The trouble is that most new host functionality is
    only likely to be needed and be useful in a new
    architecture which needs it at both ends.  An
    exception would be the ITFH function of Ivip -
    which could be installed in some host operating
    systems to reduce the load on external ITRs.

and

2 - The upgraded functionality was for the operating
    system only, and not for some or all applications.

    While one might expect Apache and major browsers to
    rapidly adopt new OS features, there are many more
    applications which are not being maintained (games
    various Windows shareware etc.) so a new architecture
    which requires host application upgrades is unlikely
    to be be fully, or perhaps even widely, adopted.

    Presumably a new OS function and new application
    functions which are needed for it to be useful will
    also involve new system calls - perhaps new types of
    system calls and interactions between the OS and
    applications.  For instance, RFC 4821 Packetization
    Layer Path MTU Discovery looks like a nightmare to
    program and debug since all the applications which
    have their own packet acknowledgement code have to
    give and take information in new ways with the OS.

Any upgraded application must still be fully functional with a
non-upgraded OS, so this splits the application into two modes of
operation, which is likely to seriously increase complexity and
debugging problems.

There remain a large number of items of equipment, such as old RAQ
servers, web servers in hosting farms, DSL routers, routers in
general, firewall software, applications etc. which people's
business actually depend upon and which are not in a state of active
software development, with robust or automated updates.

In the case of web servers in server farms, perhaps the machine is
running fine with an old version of some Linux or Unix operating
system which is no longer maintained.  To upgrade to a version which
is maintained, and able to receive regular updates, would require
taking the machine off-line for hours or a day, so a new OS can be
put on the hard drive.  Then it is necessary to reconfigure all the
servers, upload the data etc.  This is costly and error-prone.  I
need to do this for my server at Servepath.com, and have been
putting it off for months.

So overall, I think that new architectures which rely on host
changes will not be successful.  Such architectures generally are
ambitious and want, quite reasonably, to have host OSes and perhaps
applications at both ends of the communication behaving in new and
smarter ways.

  - Robin



--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg