comments inline<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
Hi Marc, thanks for the feedback.<br>
<br>
If I understand your suggestion correctly, the problem I see is that<br>
the ephemeral node based solution  it will signal problems on the<br>
hosts, but not on the wire. Two peers A, B might be alive, have<br>
conectivity with ZK, the tunnels be technically alive and working<br>
A->B, but failing B->A. In this situation, ephemeral nodes wouldn't be<br>
deleted. Does that make sense?<br>
<br></div></div></blockquote><div><br></div><div>I was not talking about having about having the host itself in zk, this way we would have the problem you mention, I was thinking of having a connection to zk (as an ephemeral node) tied to the tunnel itself. </div>
<div>But after reading your e-mail I think that the  "hey, there is no incomin data on our tunnels" solution you are proposing is far easier to understand + implement. This zk solution was a bit of an overkill. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
On a side note, and more directed to @Adam:<br>
<br>
Pino and I were discussing yesterday if we really need that much<br>
granularity in the diagnostic.<br>
<br>
Our current proposal gives value under the assumption that each host<br>
depends on specific network conditions and therefore it's important to<br>
report exactly what host, what tunnel, and what direction seems to be<br>
dead.<br>
<br>
But in practise, a bunch of hosts will depend on the same network<br>
conditions (e.g.: all are in the same subnet). And therefore, if the<br>
subnet is unreachable from outside all tunnels will be dead, so<br>
reporting the problem for each tunnel is simply redundanty.<br>
<br>
With this in mind, it may be enough to implement a much simpler<br>
proposal whereby every MM agent would simply report if it's receiving<br>
inbound data on tunnel ports. When they don't, having all hosts on the<br>
subnet saying "hey, there is no incomin data on our tunnels" is<br>
probably good enough to know where to investigate. For example, would<br>
this have been enough in the Netflix PoC?<br>
<br>
What do you think?<br>
<br>
Thanks!<br>
/g<br>
<br>
On 19 February 2013 23:12, de Palol, Marc <<a href="mailto:marc@midokura.jp">marc@midokura.jp</a>> wrote:<br>
> Hi all,<br>
><br>
> I agree that the results will need to be stored in Cassandra, for what Galo<br>
> said, the metrics are there and the GUI already knows how to get them.<br>
><br>
> About this 'are you there' problem. I wonder if we could use zookeeper's<br>
> ephemeral nodes. This nodes exist in zookeeper as long as the session who<br>
> created them still exists. We could create a znode for every tunnel, tied to<br>
> the session. If a tunnel disappears or stops working the ephemeral node<br>
> disappears (don't know how, we should see the details here). There could be<br>
> some watchers set in place to notify the responsible for the tunnel<br>
> recreation.<br>
><br>
><br>
> On Tue, Feb 19, 2013 at 5:27 PM, Navarro, Galo <<a href="mailto:galo@midokura.jp">galo@midokura.jp</a>> wrote:<br>
>><br>
>> Just to clarify after talking w. Guillermo:<br>
>><br>
>> Even though we don't need to active listen for an ACK received (for<br>
>> the reasons explained before), we do need to implement a mechanism to<br>
>> receive and reply to "are-you-there" messages received on one side of<br>
>> the tunnel.<br>
>><br>
>> /g<br>
>><br>
>> On 19 February 2013 16:50, Navarro, Galo <<a href="mailto:galo@midokura.jp">galo@midokura.jp</a>> wrote:<br>
>> > On 19 February 2013 16:31, Guillermo Ontañón <<a href="mailto:guillermo@midokura.jp">guillermo@midokura.jp</a>><br>
>> > wrote:<br>
>> >> On Tue, Feb 19, 2013 at 4:21 PM, Navarro, Galo <<a href="mailto:galo@midokura.jp">galo@midokura.jp</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>> Hi Guillermo, thanks for the quick feedback! Some comments below<br>
>> >>><br>
>> >>> >> - TunnelPorts become active on each side of the tunnel, the<br>
>> >>> >> TunnelDoc<br>
>> >>> >>   becomes aware of local ports and starts taking care of them.<br>
>> >>> >> - Regularly, for each cared-for tunnel the TunnelDoc:<br>
>> >>> >>     - Sends a packet to the other peer<br>
>> >>> >>     - Logs variation on RX value of the PortStats on the tunnel's<br>
>> >>> >> local<br>
>> >>> >> port.<br>
>> >>> >>     - If variation = 0, increment a "no-increment" counter<br>
>> >>> >>     - If "no-increment" counter > threshold, trigger alert message<br>
>> >>> >> for<br>
>> >>> >>       lack of connectivity on the REVERSE direction of the tunnel<br>
>> >>> >> (e.g.:<br>
>> >>> >>       if the TunnelDoc at A spots no RX, the alert refers to loss<br>
>> >>> >> of<br>
>> >>> >>       connectivity from B to A).<br>
>> >>> >>     - Implement whatever corrective measures upon receiving the<br>
>> >>> >> alert<br>
>> >>> >>       (typically, the DatapathController could recreate the tunnel)<br>
>> >>><br>
>> >>> > This is not a lot of extra traffic, but the number of tunnels does<br>
>> >>> > grow<br>
>> >>> > quadratically with the number of MM agents. I propose a slight<br>
>> >>> > variation<br>
>> >>> > on<br>
>> >>> > the above to avoid sending traffic on non-idle tunnels, along the<br>
>> >>> > lines<br>
>> >>> > of<br>
>> >>> > what is done by IPsec's dead peer detection:<br>
>> >>> ><br>
>> >>> > <a href="http://www.ietf.org/rfc/rfc3706.txt" target="_blank">http://www.ietf.org/rfc/rfc3706.txt</a><br>
>> >>> ><br>
>> >>> > Basically, from the POV of view of one of the nodes, it looks like<br>
>> >>> > this:<br>
>> >>> ><br>
>> >>> >    * Monitor idleness (by looking at RX as you outline above) and do<br>
>> >>> > nothing<br>
>> >>> > and consider the tunnel healthy while idleness doesn't go above a<br>
>> >>> > certain<br>
>> >>> > threshold.<br>
>> >>> >    * When the tunnel becomes idle, send an "are-you-there" packet to<br>
>> >>> > the<br>
>> >>> > Peer (we could just use the tunnel-key for this).<br>
>> >>> >    * When an "are-you-there" packet is received, reply to it with an<br>
>> >>> > Ack.<br>
>> >>><br>
>> >>> This is definitely better. I messed up copypastes badly but the idea<br>
>> >>> was basically what you explain, the "send packet to another peer"<br>
>> >>> would be conditioned to several cycles without increment on the<br>
>> >>> "no-data-increment" counter.<br>
>> >><br>
>> >><br>
>> >><br>
>> >> But I think that for this to work you need the 'ack' reply, would it be<br>
>> >> included? Otherwise a host may be receiving traffic (non-idle) but not<br>
>> >> sending, and would never send any 'are-you-there' packets to the other<br>
>> >> side<br>
>> >> because its RX is increasing.<br>
>> ><br>
>> > But note that A is only monitoring *incoming* connectivity (B->A).<br>
>> > This is because once the packet leaves A it's agent can tell that<br>
>> > something is broken in the line, but not in what direction (is PING<br>
>> > lost bc. A->B is cut, or ACK lost because B->A is cut?). We need to<br>
>> > report health of each direction.<br>
>> ><br>
>> > So, A doesn't care about A->B. It only asserts that data is arriving<br>
>> > from B. With this in mind, once A's agent sends the "are-you-there"<br>
>> > message it doesn't really need to pay attention to the ACK.<br>
>> ><br>
>> > From the other side, B will do the same in reverse. If the<br>
>> > "are-you-there" never arrives because A->B is broken, B will notice<br>
>> > the static rx count and start a health check of the A->B direction.<br>
>> ><br>
>> > Does that make sense?<br>
>> > /g<br>
><br>
><br>
</div></div></blockquote></div><br>