Talk:Anycast

message: Ah. I've just read RFC 3068. I'll put that text back. -- The Anome 21:58, 6 Jul 2004 (UTC)
replies: text: 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)
replies: text:  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)

text:  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)
replies: text:  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)

text:  I believe the first publication mention of anycasting was RFC 1546https://tools.ietf.org/html/rfc1546, 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)
thread_title:  Misc 

message: What's the reason for forcing lowercase () for the article title --Kvng (talk) 21:34, 6 September 2011 (UTC)
thread_title:  lowercase 

message: 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)
replies: text: "Geocast" isn't a thing.  Someone should edit the graphic to remove that. Bill Woodcock (talk) 03:12, 21 February 2014 (UTC)
thread_title:  Geocast explanation missing 

message: 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)
thread_title:  "Anycast generally results in a several-fold increase in total network utilization..." 

message: 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)
thread_title:  Limitations 

message: 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)
thread_title:  Anycast diagram query 

message: 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)
thread_title:  Content delivery networks 

message: 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:
*Anycast
*Broadcasting (networking)
*Geocast
*Multicast
*Unicast
One obvious problem with the edits is that  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)
thread_title:  Addressing methods 

message: 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)
replies: text: 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)
thread_title:  Definition