Re: review of draft-ietf-shim6-failure-detection-03.txt

[Jari Arkko <jari.arkko@piuha.net>]

Iljitsch,

> One way to address this is to split the reachability detection into a 
> shim-specific part (the keepalives) and a generic part (the path 
> exploration), so that the generic part can evolve independent of shim6.
>
> Note that I'm not saying this is necessarily the path we should take, 
> but seeing that there is other stuff that can also benefit from 
> reachability detection, it certainly seems prudent to think about 
> this now while we still have the opportunity to easily go into 
> another direction.

It would be great if we could do something like this,
but it seems that the employment of multiple different
protocols (in the protocol number/port number sense)
could lead to a situation where exploration says we have
connectivity but Shim6 says we don't. I'd like to avoid that.

>> But many
>> scenarios that I can see do not necessarily work well with ICMP,
>> particularly with one version of ICMP. In MOBIKE, for instance,
>> it would have been inappropriate to use anything else than the
>> regular NAT-T UDP at the bottom, because only that can show
>> whether actual MOBIKE/IKEv2/IPsec traffic will get through. And
>> what about HIP running over IPv4?
>
>
> Since we're determining unidirectional reachability, NAT is not 
> actually as big a problem as it would ordinarily seem. The big issue 
> with NAT is making sure that both ends know the addresses on both 
> sides and there are translation rules that allow incoming packets to 
> be delivered. But you're right ICMP won't work with NAT, we'd have to 
> use UDP for that. But I guess it would make sense to develop a non-
> NAT IPv6 version first and then see what needs to be done to make it 
> work over IPv4 with NAT.

In a sense, that is what we are doing -- developing the IPv6 and Shim6
version
of the reachability protocol. With the knowledge that it is insufficient
for,
say, HIP use with NATs and IPv4. The question is if the separation into
two components or the use of ICMPv6 makes future use in other contexts
easier. Frankly, I don't know if that's the case.

>> But as a general rule, I'd like to
>> get a working, as simple as possible Shim6 mechanism out there.
>> Even if its not optimized for all situations. We can work on  extensions
>> like fate sharing between contexts later, too.
>
>
> I disagree with that approach, I think we should make the first 
> version as good as it can be. I don't see much added value in 
> finishing this work a little earlier, we're obviously too late to 
> avoid PI in IPv6 now (if that can be avoided it won't be because of 
> shim6) or avoid having legacy non-shim IPv6 implementations out 
> there, but at the same time IPv6 isn't deployed on any measurable 
> scale yet so there is still (some) time.

I agree that we do not need to ship Shim6 this month. But efforts like
this have a best-before date in any case. At some point the interest
in implementations and WG contribution is going to go down, if we
don't deliver a spec that people can start to play with.

>> Was there other issues related to probe storms? We do have
>> exponential back-off.
>
>
> Not really. There is no description of how this works.

The newest drafts do have some description of it. Take a look
to see if its sufficient.

>
>>> Another thing that's missing completely from this draft is a
>>> discussion of how to use address pair preference information. This
>>> makes it impossible to address traffic engineering needs.
>>
>
>> This is important, but can be addressed separately.
>
>
> No, that would make it MUCH harder, as this will only work well if 
> both ends implement it. And we're getting flack for not paying 
> attention to traffic engineering as it is.

OK. (But separately != optional). If you think we need it
from day one, lets do it.

>>> Data packets as opposed to what other types of packets?
>>
>
>> I added a clarification. Basically, its all packets including both
>> ULP packets and SHIM6 control messages, but NOT keepalives
>> or probes.
>
>
> I think it's a good idea to consider TCP ACKs with no user data as 
> non-data packets that don't need to generate return traffic as well.

Hmm... in order for that to be useful (as an optimization), it would
have to be
supported by both sides. That would set a requirement that the shim layer
can peek inside the TCP packets. Not sure if we want to do that.

>>> So when we receive a keepalive from the other side, _we_ stop sending
>>> keepalives? This may be the right thing to do, but it's not obvious
>>> to me why. Some explanation would help.
>>
>
>> Keepalives are only used if there's one-way communication. Since the
>> other side sends a keepalive, its not sending anything else at that
>> time. Hence we have no need for keepalives.
>
>
> But do we need this rule? It may make implementations more complex 
> without any benefit.

Assuming we want to avoid keepalives for periods of bidirectional
communication or silence, I think we do need it. If you send a keepalive
based on a keepalive, you don't have a termination condition.

> Why not leave it up to the implementers? If we say that after 10 
> seconds the full path exploration starts, implementers are free to 
> experiment with what works well (3, 4, 8 seconds between keepalives) 
> without any need to revisit the spec.

I have now made it clear that these are recommended defaults,
but that more experimentation is needed to determine the best
values. And that implementations can choose what they want to
do.

>>> I believe that since the id of the last received probe is included,
>>> the iseeyou flag is unnecessary.
>>
>
>> But we also have the case where you report seeing data packets but
>> no probes.
>
>
> Good point. But couldn't that be solved by using a special value for 
> the last seen id?

Sure. Its just a question of how to encode that information in the
bits.

>>> Although copying back the last seen id seems to do the job, I can't
>>> help but feel that it would be preferable to add timers to reach
>>> round trip times and copy back more received ids and also sent ids.
>>> This allows the receiver of a probe to determine which of the probes
>>> that made it to the other side did so faster, so it can select the
>>> address pair with the shortest round trip time.
>>
>
>> Right. But all that can go into extensions. I'd like to have the
>> minimum necessary to get this spec done.
>
>
> Let's split the difference and specify the fields, but make (most of) 
> their use optional.
>
> I severely dislike having fixed length data in TLV format, because 
> that makes parsing much harder. If you look at Van Jacobson's work 
> with TCP you'll see that a fixed header allows extremely streamlined 
> implementations.

If we move the current option contents to the messages (as discussed
earlier),
this will simplify things a bit. I think we need to retain TLVs for the
rest, because
that allows multiple appearances of the same value (e.g. reception
report) and
future extensibility.

Re: timer values etc. I don't currently have a good idea of what the
behaviour based on these fields would be. Maybe you do.

>>> Including sent ids along with the addresses the probe with that id
>>> was sent to helps the receiver determine that some probes didn't make
>>> it (yet). If a probe didn't work in one direction of an address pair,
>>> it's reasonable to assume that it may also not work in the other
>>> direction and try other pairs first.
>>
>
>> True as well, but again perhaps material for future
>> optimizations.
>
>
> I really like having multiple ids for earlier probes in there, it 
> should cut down on the number of packets exchanged, and I also 
> suspect that there could be race conditions when certain packets are 
> lost and not others so that an implementation that only echos the 
> last seen id may stay in an oscillating state, but I haven't been 
> able to think of an example so far.

The spec says it should return multiple identities, everything that it
has recently seen
(up to some reasonable limit).

--Jari