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

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

On 29-jun-2006, at 12:50, Jari Arkko wrote:


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. 


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.
See my message "reachability also for non-shim protocols". My conclusion is that there aren't sufficient benefits in sharing a reachability detection protocol, sharing reachability hints between protocols would be better. 


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.
Yes, it would have to be on both sides. But it's simple enough: next header = 17, remaining length for the packet = data offset. Is that really problematic? 


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.
No, we NEVER send a keepalive for a keepalive (or any other packet that doesn't have any upper layer protocol following the shim header). 


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.


Ok.


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.
The same thing multiple times doesn't necessarily need TLVs, but yes, we should keep TLV for real options, i.e., ones that are optional :-) and may be defined in the future. 


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.
If you send packets over different paths and start sending packets at fairly short intervals in the beginning, it's entirely possible that packet 2 from A arrives at B earlier than packet 1. It's also possible that a particular round trip has a fast leg and a slow leg. If we know how long the remote host has had the packets we sent before sending a reply, we gain relative delay information for each of them, allowing us to arrive at very good delay information which can then be used to select the best address pair in each direction.
I.e., when you go to Montreal and come back, say, 8 days later, I don't know whether your RTT is 2 hours and you stayed there for 190 hours, or if your RTT was 3 days and you stayed 2 days or something in between. If I know how long you were on the ground I can calculate your RTT and if several people take the trip I can draw some conclusions about who had travel delays, and even infer some information on whether it was on the way out or on the way back. 


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


Excellent.

Iljitsch