On Tue, 2002-11-12 at 12:07, Keith Moore wrote: <snip - and agree> > > > Are we trying to solve a problem at the network layer, which impacts the > > transport layer, which really is best and most appropriately solved at > > the application layer ? > > The overhead of recovering from renumbering is close to requiring each > application to implement TCP at layer 7. (for instance, if a connection > fails due to an address change, and you don't get a clean close, the app > has no idea whether the data it has sent to its peer really got there. > So the app needs explicit acks and to explicitly buffer all un-ack'd > data in case it needs to retransmit). >
That's a good point, one I had overlooked. > Do you really think that it is is optimal to burden all apps with this? > No I don't, although I'm probably only suggesting that applications that don't want to be impacted by a TCP session failure (caused by renumbering, interface failure etc) do need to implement this in some way. All the rest of the applications that don't have such a high availability requirement should be able to accept very occasional TCP failures due to renumbering events, interface failures etc, as long as they didn't occur very regularly, which is and would be the case. > > In the context of the End-to-End argument, could TCP/SCTP be seen to be > > a performance enhancement for the application, rather than trying to > > provide "perfect" reliability ? > > > > Should it really be "dumb network, smart hosts, wise applications" ? > I suppose what I'm really trying saying here is that for most applications, the "dumb network, smart hosts" is enough. On the other hand, for the smaller number of very high availability applications, the smart hosts are smart enough nearly all the time, though not quite enough to be acceptable. In that case, an application will need take some ownership of the reliability it requires. A "wise application" (or rather developer) would weigh up its reliability and availability requirements, and if TCP can't deliver them, due to occasional interface failures, or occasional renumbering events, then it will have to take measures of its own - with the associated costs of implementing basic reliability mechanisms. Hmm, even I thought it was just re-implementing TCP when writing the last paragraph. Do any mission critical applications today use TCP (retorical question)? If so, how do they cope with interface failure tearing down TCP sessions, other than just failing.There are ways of using networking tricks like virtual interfaces inside a host etc to increase interface and therefore IP address availability, but are there applications out there today that take ownership of some level of their own reliability requirements ? > Why not have each layer doing its job without trying to outsmart the others? True. The issue we seem to be having is that by moving from pseudo-permanent addressing to semi-dynamic addressing, we are reducing or taking away one of the properties TCP has relied on. site-locals addressing is trying to restore that property, but the consequential complexity to many other areas (DNS, routers, security etc) scares people. Accepting that TCP sessions aren't going to live as long as they used to when using global addressing, and giving the applications that have such high TCP availability requirements some of that responsibility may be a way of moving forward. However, I can't see a typical organisation changing its global prefix more than once every thirty days. If you do, maybe Mobile IPv6 is the thing for you (I could be speaking out of turn here, I don't know much about Mobile IPv6). If you are running mission critical applications that require very long lived TCP connections you are far more conservative in making network infrastructure changes, addressing being one of them. You probably only review your ISP contracts once every 12 months, and make it a contractual decision that your globally assigned prefix will not change during that period. If you wish to change ISPs, one of the associated costs is mission critical down time, which you would weigh into the costs-benefit of changing ISPs. Mark. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
