[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on REAP draft

Jari Arkko wrote:


I don't understand the comment text that says:
   The REAP design allows performing both failure detection and address
   pair exploration in the same sequence of messages, without a need to
   designate a specific point when the current address pair is declared
   inoperational and the search for a new pair begins.
It seems like the timout event that triggers a message with Y=no is quite
different than the one that triggers a message with Y=yes. And the one that 
causes a message with Y=no is the point at which the current address pair
has been declared inoperational. So I'm not convinced it is helpful to
be able to have the "FBD keepalive" (the payload reception report) and
the event reception report in the same shim6 message.



The Y bit causes indeed different behaviour. We can easily
define this as a separate message. For the moment I'm thinking
that there's more common in Y=0 & Y=1 than there's different.
Hmm - I didn't read the text in the draft as being about the Y bit, but being an argument that the "payload reception report" and "event reception report" being carried as part of the same Probe message. 

I agree that having Y=1 and Y=0 in the same message seems useful.


For instance, it seems useful to carry same information about
what traffic/probes you have seen.
I can understand that it is useful to say that you've seen traffic but not sent anything back - hence a FBD keepalive (which the draft calls payload reception report). 
And one needs to be able to provide the probes one has seen.
But I don't see any case when both would be used at the same time.


It also seems useful (at least
in thinking some future load-balancing or true multipath
extensions) to be able to send multiple keepalives.


You mean keepalives for multiple context between the same pair of hosts?
That might be a useful optimization, but to carry those semantics in a payload reception report, you'd need to include the actual locator pair on which you've received things. 


Finally,
after short transient failures you may end up receiving the
peer's keepalive or a payload packet instead of one of the
explore acks. To me this says that behaviour-wise, we need
to be able to treat all this information.
Yes, but the semantics are quite different between {keepalive, payload} and explore.
The first indicates that the receive path is working, but nothing about transmit. The explore has explicit information about what's working.
Hence I think it is actually easier to understand if the keepalive is separated from the explore. 


I can't find one. Should this happen it would be an indication that
payloads continue to be sent as alternate locators are used. In that case the payload reception report might not contain enough information to tell which 
locator pair was used; the locator pair might have switched due to the
exploration. So *if* there is a case when payload reception reports and event 
reception reports are used at the same time, then the payload reception
report needs to include the locator pair(s) on which the payload(s) were
received.



Yes. I don't remember whether I added this to the draft - I
guess not since you are asking. For NAT purposes it would
be also necessary to know where packets (including probes)
are received from.


There is a NAT note about that.
My point is that this applies when multiple locators are in use at the same time, for instance if we want to optimize things when we have multiple contexts (whether for forked contexts using different locator pairs, or contexts for different ULID pairs between the same hosts). 

   Erik