Re: [core] Anycast and CoRE

[Carsten Bormann <[e-mail]>]

Hi Jim,
hi Christian,

I think the assumption here was that the anycast address is usable as a unicast address.
So the server can reply from the same address that it got the request on (as it always should if it has multiple addresses, which is almost always true in IPv6).  The special exception for multicast is not invoked (and not needed).

Of course, there is an assumption here that the routing won’t change quickly enough that the reply is swallowed by a BCP38-like mechanism.  If that happens, I’d say this is like any other routing-instability induced packet loss, and for a piggybacked response the client will simply retransmit.

If the anycast goes through an ECMP-like mechanism, multiple requests in a block-wise transfer would still go to the same server.  If there is completely random distribution, well, you get what you sowed…
(That is the general load balancer problem.)

Grüße, Carsten


> On Dec 12, 2018, at 21:58, Christian Amsüss <[e-mail]> wrote:
> 
> Signed PGP part
> On Sat, Dec 08, 2018 at 02:58:54PM -0800, Jim Schaad wrote:
>> I am trying to figure out if Anycast is supposed to have the response
>> on the Anycast address like Unicast does, or if it should be returned
>> on a Unicast address.
> 
> I can't offer guidence, just my .02€:
> 
> The client may not know that it's talking to a multicast server.
> Therefore, the client would not correlate any messages from a unicast
> address.
> 
> As for the block-wise transport, the effects would not be too bad:
> If it's a stateless transfer, all is fine. If the anycast servers have a
> magic backplane that distributes incomplete transfer states, likewise.
> Otherwise, the transmission needs to be restarted.
> 
> Can't say much about DTLS, but in OSCORE that'd be an ideal use case for
> the appendix B2 protocol. When the route flips, the client will get a
> 4.01 once and continue exchanging data with the protocol's Req2 message.
> 
> Best regards
> Christian
> 
> -- 
> There's always a bigger fish.
>  -- Qui-Gon Jinn
> 
>