Re: [tsv-dir] Re: TSV-DIR Review of draft-ietf-shim6-protocol-09.txt

[<[e-mail]>]

> When traffic is flowing in both directions or when there is no  traffic, 
> there is no need to send keeplives.

That makes sense.  It would be helpful for the protocol document
to include this explanation in the keepalive section (and also for
the Failure Detection specification to remove the reference to
TCP Keepalives, since they're unrelated).

>> The SCTP algorithms make extensive use
>> of transport layer information such as retransmission counts, which
>> the SHIM6 Failure Detection document seems to assume will be 
>> unavailable.
>
> Right. Shim6 must work for all kinds of communication. However, it  would 
> be good to make use of transport protocol knowledge when  available. You 
> feel there are missed opportunities in this area?

Yes.  If the transport layer can make the information available, then
it seems to me that Failure Detection could be improved, providing
for TCP a better approximation of the functionality in SCTP.

>> In general, it would not be desirable for SHIM6 to initiate the re- 
>> homing of a TCP connection due to a transient failure.  Link layer "down"
>> indications or resulting address deprecations are examples of this.
>
> The trouble is, how do you know a problem is transient?

You don't.  That's why "link down" indications are best ignored by
both the Internet and Transport layers.

> About address deprecation: I do seem to remember a discussion where  the 
> conclusion was that deprecation is no reason to stop using an  address 
> just because it's deprecated. Telling the other end that an  address 
> should no longer be used when it's deprecated would have that  effect, so 
> if the proto document mandates that, that could be  problematic.

It is suggested not mandated.  However, it's hard to see a circumstance
in which this would be helpful (and it will often hurt), so I'd prefer to
see the suggestion removed.

> (One scenario is a router that no longer sends RAs but still continues  to 
> route, it would be possible to use the addresses after they've  become 
> deprecated until they become invalid in this case.)

Yes.

>> 6.  Interactions of SHIM6 with congestion control.  Section 4.3 of the
>> Failure Detection document talks about exploration timeout values.
>> Exploration can be kicked off if no inbound traffic is
>> received within Send Timeout (default = 10 seconds).
>
>> The first observation is that the Send Timeout should probably depend
>> on the RTO estimate, as it does in SCTP.  Otherwise we could have a
>> network with a high RTO and SHIM6 exploration could commence after  RTO 
>> is backed off only a few times.  This would be undesirable from a 
>> congestion control point of view.
>
> We need the timeout to be somewhat long to accommodate the case where  a 
> host receives a packet, then does processing and finally sends an  answer. 
> However, it also needs to be fairly short so that we have time  to repair 
> a failure before the user, application or transport protocol  give up.   I 
> don't think alignment with the transport's retransmission  timeout makes 
> sense here.

The RTO represents the best estimate of the maximum time that can
expire until an ACK is expected.   So while I'd agree that failover should
occur prior to transport connection teardown, it is not desirable for this
to occur before a minimum number of RTOs has expired.  The time that
this takes will depend on the RTO.  For example, if the goal is to re-home
after 3 timeouts, using an RTOmin of 1 second, three timeouts will take
7 seconds.   However, where the RTO is much larger,  10 seconds might
correspond to fewer timeouts (maybe only 2).

>> The suggested value of the Initial Probe Timeout (500ms)
>> is less than RTOmin and 4 probes can be sent before initiating
>> exponential backoff.  This seems like it could violate "conservation
>> of packets".  Why doesn't exponential backoff begin immediately?
>
> Then you'd either have to send the first few probes in quick  succession 
> without leaving a reasonable amount of time for responses  to come back, 
> or it would take very long for the first 5 or so probes  to go out. 500 ms 
> is still relatively aggressive as it's well below  the maximum observed 
> RTTs on the internet.

The issue is kicking off SHIM6 exploration simultaneously with
transport layer congestive backoff.  While SHIM6 exploration is designed to 
find
alternate paths, the paths could still share a bottleneck.   So while 
transport
layer congestive backoff  is attempting to let packets drain from the 
network,
SHIM6 will be injecting more packets.  In these situations, aggressively
resending Probes will not improve the likelihood that they will get through.

With respect to 500ms being "well below the maximum observed RTT on the
Internet", I'd observe that RTOmin is set at 1 second.  So my recommendation
would be to set the minimum Initial Probe Timeout to RTOmin, and allow
upwards adjustment based on the RTO estimate, if available. 


_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf