Re: [core] Anycast and CoRE

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Christian Amsüss <[e-mail]>
> Sent: Wednesday, December 12, 2018 12:59 PM
> To: Jim Schaad <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [core] Anycast and CoRE
> 
> 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.

Would this potentially have a problem if one is using ETag for correlation?  I would not assume that the ETag values would be the same on both servers.  I think you might be in a situation where you need to restart the block transfer from scratch.

> 
> 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.

I guess this is a case where one would expect that the same credentials would be on all of the anycast machines since otherwise one would not be able to do this roll over.  You might get a 4.01 and need to get a new token from the AS instead.

Jim

> 
> Best regards
> Christian
> 
> --
> There's always a bigger fish.
>   -- Qui-Gon Jinn