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

Re: TSV-DIR Review of draft-ietf-shim6-protocol-09.txt

[redirecting to the shim6 list]
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


You're right, this is not made explicit in the document.
I'll leave it up to others to decide if another iteration is warranted, but if so, i think we should add this. 


(and also for
the Failure Detection specification to remove the reference to
TCP Keepalives, since they're unrelated).


You're right.


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.
Which REAP values do you think could be changed based on information available to transport protocols? 


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.
A multihoming solution ignoring outages kind of defeats the purpose. :-)
Note that we explicitly say that this applies to local knowledge that an address doesn't work, although then the issue is confused by mentioning deprecation, which leaves the address involved still reachable.
The issue is also different from regular operation, because if I pull out my ethernet cable when I'm not running shim6, the only two options are keeping the session open until it times out or giving up immediately. The latter is suboptimal because I could put the cable back in before the session times out. But with shim6, it's possible to rehome the connection to a different interface so it keeps running whether or not the cable is plugged in again.
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.


Marcelo, Erik?
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).
Ok, the text about how the retransmission timeout is computed in RFC 793 is somewhat complex, so rather than risking getting it wrong, let me ask you: what are values one would expect to see for the RTO in a number of common deployments, such as a low RTT / high bandwidth LAN, a long fat pipe, and a low bandwidth / high delay mobile link?
We do not mandate an interval for generating keepalives except a maximum of 8 seconds, but I would expect implementers to go for 3 seconds based on the 10 second timeout. The other end can't then dynamically reduce the timeout, at most it can increase it.
It would be possible to adjust the keepalive interval based on RTT estimates, though. 


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 sending Probes will not improve the likelihood 
that they will get through.
Hm, I don't see that happening very easily. If there is a routine level of congestion, you would still expect to see at least one packet coming in every 10 seconds. So it should be rare for path exploration to be triggered by congestion. If the congestion is bad enough that this does happen, then I'd consider that a feature, as shim6 will then most likely select another path, avoiding the congested part of the network.
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.
In a transport protocol, you're sending every packet to the same destination over (presumably) the same path, so there is no value in sending message 2 if there's still a chance that there will be an answer for message 1. In REAP, ideally, we'd want to probe all paths immediately and then use the one for which we get the first answer. That would be too aggressive. 500 ms is short enough to allow an answer to come back in 95% or so of all cases, but it also has the property that if the first probed path has a rather long delay (700 ms mobile link) while the second probe has a much better delay (150 ms wired) then the second probe will see a reply faster than the first one so we select the second path, which is probably the right choice in this case.