|
Hi Phillip, Philosophy is a bad thing for exact science, for example, engineering. Let me give you an opposite philosophical example: If all decisions are cut in stope for ages then mistakes would be only accumulated till the whole system would collapse. Is it what you imply below pushing “principles”? You see, it is possible to prove anything by philosophy. Any technological nonsense. And the discussion could be eternal. Conclusion: Arguments should be only technical and commercial that are verifiable. Moreover, anycast and multicast are both hacks for IP architecture. Hence, it is peculiar that you prize multicast but deny anycast. The rules are important to coordinate people, if everybody would be pulling in different directions at the same time – it would be a mess without any progress. Hence, I believe that the existence of RFC 7094 is the tombstone for Anycast. Anycast for stateful traffic is just banned by IETF. Hence, it is better to follow the IETF decision. Anybody that would assume that Anycast is possible to use (for stateless connections) is acting against standards at his own risk. Do not complain later that
your proprietary solution does not work. Hence, no problem that LINUX has finished it off. Anybody could abuse RFC 7094. Would like something different – welcome to 7094bis to release this ban. Just discussion in any alias may help to reach a common understanding but not to release the formal Anycast ban for stateful connections. Even Linux parch revert is not a full solution to the problem – RFC 7094 is awaiting for the next engineer to abuse it. Why I believe that Anycast is needed for connections too. IMHO: This general use case is very strong: The final destination computer would never scale to the size needed. It would be always many computers, for some use cases many thousands of computers, up to the situation when traffic would be bigger than the capacity of any stateful
Load Balancer that may be installed in front of these computers. Then one would need to load balance on the stateless routers (or even network of routers) to achieve the needed scale for load balancing. It is exactly what is banned by RFC 7094. Load balancing by DNS is possible too, but it has many differences – it is not an equal replacement. Eduard From: ietf [mailto:ietf-bounces@xxxxxxxx]
On Behalf Of Phillip Hallam-Baker Traffic schemes have a principle that once a right of way is established, any competing mode of transport wanting to cross that right of way is responsible for building the necessary bridges etc. I raise this not to propose it as a principle for the Internet but rather the opposite, to call it out as an anti-pattern. If the IAB has an architectural role, it is maintaining the thinness of the thin waist: Keeping complexity out of the Internet core is important and requires vigilance. The anycast over TCP discussion reminds me of a much older argument in the industry when people who got used to hooking MSDOS system calls at particular addresses were wont to scream like banshees each time a new version of MSDOS came out
with the entry points moved. From an architectural point of view, ANYCAST is not a thing, it is a hack. A hack that is useful but one that was never guaranteed to support TCP. The Internet architecture was designed to support UNICAST. The fact that architecture allows
us to share an IP address between hosts within a BGN ASN is interesting and useful but not a core commitment by the architecture. If people want to build stuff on that quicksand, so be it. But those who do so have to understand they are building within very
limited constraints and there is no long term commitment to support any use they might establish outside those constraints. Sure, there will be people who have come up with some ingenious scheme that allows systems to work because the deployed infrastructure currently provides stronger guarantees. But fortunately the IETF does not have the ability to insist
such guarantees be continued so we really don't have to debate whether we should do something we can't. The cost of insisting that squatters rights be preserved would be a gradual ossification of the core as every change is required to preserve the rights of the owners of riparian rights. As for QUIC, Christian is half right. Yes, QUIC does behave in a way that is more compatible with ANYCAST. But QUIC was never designed to work in that way and hence does not guarantee it will work that way. Fortunately, QUIC is not the replacement for TCP, it is one tool that does the same job and the most important single change in QUIC is that from this point on every application can choose their own transport. The principle that the platform
providers are gatekeepers for transport provision has been broken. Censorship resistant protocols is a very longstanding interest of mine and I would like to see innovation in that area. I really can't see much that ANYCAST brings to the table beyond the discovery phase but Multicast certainly interests
me a lot. There are three types of transport protocol are possible: 121) One to One 12M) One to Many M2M) Many to Many The last is of course the holy grail for some people, peer to peer goodness and all that. As an applications guy, I have absolutely no interest in that type of transport, reliable or not. Even when my application is peer to peer. A reliable transport with DDoS resistance properties supporting 121 and 12M that could make use of multicast and hide the fact it had been used from the application layer would be very very useful. QUIC arrived at IETF as an optimization that Google was using and wanted to standardize. Which is a completely valid mode of IETF work. But if we want to do interesting stuff, QUIC is not the test bed to build upon. We need to do research
first and challenge the prior assumptions baked in before the effort began. PHB |
