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

Re: Comments on REAP draft

Erik Nordmark wrote:
The protocol as described by the state machine doesn't seem to work for ULPs 
that, even when they are "unhappy", space their retransmissions more than
3 seconds apart. This is because starting in "idle, when the ULP sends one packet, we move to "suspected peer problem". But after 3 seconds ("outgoing 
timeout") we move back to "idle".
I don't think the protocol should make any assumptions on how frequently
an unhappy ULP might retransmit.


Agreed. This was one of the known problems.


When I asked Jari about this before I think he said it was an attempt to
avoid a FBD keepalive message after the ULPs go silent (and are happy).
But I think this is fundamentally unavoidable. If the ULPs finish exchanging packets, then I don't see how we can avoid having one end (the one that last 
received a ULP packet) send a single FBD keepalive to the peer.


Probably.


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.
For instance, it seems useful to carry same information about
what traffic/probes you have seen. It also seems useful (at least
in thinking some future load-balancing or true multipath
extensions) to be able to send multiple keepalives. 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.

But lets see what the full design is before we decide this.
Is there an example of a case where both a payload reception report and an 
event reception report is included in the same packet?


I think this is possible.


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.


Looking at the packet diagram on page 16, I was also confused by the who
actually detects the need to send a Y=no event.
I think there are three cases to look at in more detail:
    Locator pair stops working from A to B
    Locator pair stops working from B to A
    Locator pair stops working in both direction


My definition of sending a Y=no event was that if you
know you should get something from the other end (=
i.e. you are sending something yourself) and you are
not seeing anything, then you send this event. That is,
you make (1) a local decision of when there should be
traffic and (2) a local observation that you are not
receiving traffic.
The state machine looks very complex (perhaps because I don't understand it?). 
For instance, do we really need that many different timers?


I don't like this much complexity either. There are some things
that we can do easily. For instance, we can let "garbage collection"
handle giving up, which takes away one timer and some transitions.

For the rest, I think we need as much complexity as we have
to have. The flows that are in the draft are very simple, easy
to understand. But I think our protocol spec needs to handle
all cases. There's combinations of things that may make
this hard -- or maybe its just the representation. I don't know.
The state names are hard for me to understand. For instance, it isn't really 

I'm open to suggestions...


And one failure mode is when the current
locator pair stops working in both directions, which doesn't seem to be
captured in a separate state.


I'm not sure this is a mode that we should or even can show
in a spec that says how _one_ end of the communication behaves.
We don't know about this condition if we're not sending ourselves
anything. If we send ourselves something then it looks like the
peer's traffic is not getting to us; of course this could be due
to the whole connection being broken or our own packets getting
lost. (This is where I think the name of the state is misleading.)

And then, at the time the peer sends us a message informing
us that there's a problem, the mere reception of this message
implies that we no longer have a complete problem - at least
we are getting something from the peer. Of course, the current
pair may be completely inoperational. But again, the reception
of this message means that, as far as we are concerned, we have
already moved to another pair for the incoming direction - all
that's left is telling the peer that we saw his packet and he can
indeed use that pair.
I think the protocol description can be simpler than state machine description. 
I'll try to outline an event-based description in a separate email.


Ok. Looking forward to good suggestions!

--Jari