Talk:Anycast

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by Networking task force (assessed as Mid-importance).

Citizendium Porting (inactive)

This article is within the scope of WikiProject Citizendium Porting, a project which is currently considered to be inactive.Citizendium PortingWikipedia:WikiProject Citizendium PortingTemplate:WikiProject Citizendium PortingCitizendium Porting articles

Misc

Ah. I've just read RFC 3068. I'll put that text back. -- The Anome 21:58, 6 Jul 2004 (UTC)

Not sure of the context of that, but I'd love to see implementation detail -- e.g., who does this for what :)

Question: Was anycast part of TCP/IP from the beginning, or was it added later (if so, when?)? 81.82.136.176 20:22, 27 April 2007 (UTC)[reply]

As I understand it, it's more a question of the routing protocol in use, rather than TCP/IP itself. BGP4's article says that it has been the standard routing protocol since 1994. I don't know whether its predecessor protocols, like EGP, supported this, but I think they must have. (All it takes it having multiple routers announce that they are good destinations for a given IP; then any nearby traffic will be routed to them.) --kundor (talk) 21:29, 13 March 2008 (UTC)[reply]

Anycast is not a feature of any protocol, it's a way of configuring devices that are addressed using a protocol. So it's both protocol-agnostic, and transparent to routing protocols. Completely orthogonal. So in that sense, all routing protocols "support" anycast, since they don't know about it, and it doesn't interact with them. So, yes, you can do anycast in routing protocols other than BGP. OSPF and EIGRP are other protocols on which anycast is commonly used. The question "when was it added" doesn't apply, since it was never added. Bill Woodcock (talk) 03:09, 21 February 2014 (UTC)[reply]

This is correct however it is my experience that what we now call anycasting was a no-no for along time. I think I first heard the term anycast around 2001. I had heard the concept discussed back in the mid 90s but I got the impression it was being discouraged at the time. Robert Brockway (talk) 17:39, 18 November 2008 (UTC)[reply]

The first time I deployed an anycast server topology was in 1989, with servers in Berkeley and Santa Cruz. Then again in 1992, with servers in San Jose and Washington D.C. In 1995, Mark Kosters and I started pushing (mostly in the IEPG) for the anycasting of the root nameservers, but yes, we got a lot of push-back. The first time I actually anycasted a root nameserver was in 2001, with I-root. Bill Woodcock (talk) 03:09, 21 February 2014 (UTC)[reply]

I believe the first publication mention of anycasting was RFC 1546^[1], which was a product of a DARPA research project at BBN in the early 1990s. (Unfortunately I've forgotten the project name.). The problem of making TCP work with anycasting was a major impediment to practical use. From Bill Woodcock's note above, it looks like there was some parallel work going on, which Craig Partridge (the BBN project tech lead) may have been familiar with. The use of BGP routing advertisements to implement anycasting was the method used in the research project, but that was only alluded to in the RFC. Wmilliken (talk) 03:43, 28 June 2016 (UTC)[reply]

Link to 'GeoDNS' (supposedly part of BIND page) is broken. No topic of that name on the BIND page. —Preceding unsigned comment added by 75.147.139.189 (talk) 04:37, 26 May 2009 (UTC)[reply]

Link to "Anycast Addressing on the Internet" http://aharp.ittns.northwestern.edu/papers/k5-anycast/index.html appears to be broken (404) — Preceding unsigned comment added by 68.47.105.210 (talk) 00:38, 8 March 2015 (UTC) It looks like that content might be available here instead: http://www.kuro5hin.org/story/2003/12/31/173152/86 — Preceding unsigned comment added by 68.47.105.210 (talk) 00:40, 8 March 2015 (UTC)[reply]

References

^ https://tools.ietf.org/html/rfc1546

lowercase

What's the reason for forcing lowercase ({{lowercase}}) for the article title --Kvng (talk) 21:34, 6 September 2011 (UTC)[reply]

Geocast explanation missing

The graphic to the right shows ‘geocast’ but there is no paragraph to its left explaining that routing scheme. — Dough34 (talk) 18:43, 16 February 2014 (UTC)[reply]

"Geocast" isn't a thing. Someone should edit the graphic to remove that. Bill Woodcock (talk) 03:12, 21 February 2014 (UTC)[reply]

"Anycast generally results in a several-fold increase in total network utilization..."

Gunnar Guðvarðarson just removed the sentence that began with that phrase, but left the "How so?" comment, so I thought I'd provide a little context. Anycast does not cause an increase in client-server communications. However, in situations where there are multiple servers competing for traffic, as in the different servers within the set of NS records for a DNS zone, if one of those servers goes anycast, that is, its IP address becomes more easily reachable by more of the people querying the DNS zone, then that IP address will typically gain a larger fraction of the total query volume for the zone, which generally means an increase in traffic. Also, having multiple servers, whether anycasted or not, does marginally increase total network utilization in that those servers must be synchronized on the back end. So, there's an argument to be made that anycasting a server will result in more traffic, but it's very situationally dependent, not a direct consequence of anycast. -Bill Woodcock (talk) 18:35, 17 March 2014 (UTC)[reply]

Limitations

AFAICS, anycast is limited to stateless (that includes connectionless) protocols since each successive packet can be received by another server. If that's so, it is worth a section. A quick googling didn't reveal any relevant info. — Vano 16:44, 19 May 2014 (UTC)[reply]

Anycast diagram query

Hi

Apologies if this is the wrong way to raise a query.

However, in the node diagram wouldn't it make more sense to use the node closest to the sender?

Tmn0004676 (talk) 17:14, 6 February 2015 (UTC)[reply]

It might more sense if there is a clear network topology in the diagram, as it looks right now, there is no real topology, aside from where the nodes are physically drawn. In addition, it should be the nearest node in terms of network cost, not in terms of physical distance. (e.g. an operator from the US might have a very cheap (in terms of dollars) route to Europe through China (not very likely), which might influence the anycast node you would reach)

2001:67C:2564:518:9DC:32FA:51A7:99F7 (talk) 10:19, 11 January 2016 (UTC)[reply]

Content delivery networks

A citation for "The general stability of routes and statelessness of connections makes anycast suitable for this application, even though it uses TCP" are the slides from this NANOG talk: http://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf Squarooticus (talk) 19:26, 24 March 2015 (UTC)[reply]

Addressing methods

220.233.131.78 has added identical text to several articles. The text can be seen in this article at Addressing methods (where it has been for some time). I have removed it from the others with an edit summary pointing to this discussion. The articles are:

One obvious problem with the edits is that {{routing scheme}} was duplicated. Another is that it is not satisfactory to have a significant amount of text that is the same in multiple articles because that wastes reader's and editor's time and is hard to maintain. Any ideas on how the text should be handled? Johnuniq (talk) 02:26, 14 December 2015 (UTC)[reply]

The text belongs in an overview article about routing. Each specialized article shall only explain its own part and link to the others - the floating scheme does the latter just fine. — Vano 03:43, 1 January 2016 (UTC)[reply]
- Regarding the identity of the "overview article" - Routing#Delivery_semantics does this, but is a way not specific for the Net. OTOH, the current text is also not specific to the Net. So, they should be able to be fused together. — Vano 03:43, 1 January 2016 (UTC)[reply]
- As a side note, I changed the link in the scheme to point to that specific section. I feel that it's the lack of a readily available reference that has caused this. {{main}} or {{seealso}} might be a good idea, too. — Vano 03:43, 1 January 2016 (UTC)[reply]

Definition

A recent edit changed "in which a single destination address has multiple routing paths to two or more endpoint destinations" by replacing "destination" with "sender". I don't think that's quite correct but I don't know how to fix it. I think the original was trying to say that a source (sender) would not know there was anything unusual about the destination which would have what appeared to be a single destination address. However, the network would select which of the available endpoints would receive a packet from the source. The original wording needs clarification but the new wording might not be it. Thoughts? Johnuniq (talk) 23:09, 19 March 2020 (UTC)[reply]

@Johnuniq: You're correct, that edit was done by someone who didn't understand the text or the topic, and made the statement factually incorrect. The original text, which someone has already reverted, was correct. I'll take a look and see if I can think of any clearer way to state it for a lay reader. Bill Woodcock (talk) 16:55, 13 July 2021 (UTC)[reply]

Anycast other uses

I wonder if a hatnote, disambiguation page, or talk/FAQ section would be useful for dealing with other uses of the term 'Anycast'. A hatnote would say "For Sony's video products, see Sony Anycast", an FAQ could point out the AnyCast tv dongle brand seems to be unrelated to Sony (apparently piggybacking the Sony trademark). Batternut (talk) 10:28, 19 June 2024 (UTC)[reply]

[1] ttps://tools.ietf.org/html/rfc1546

[1]