> | My recommendation is to wait until the Confirm has been received to > | alter the value of an NN feature. This eliminates the problem above and > | has the advantage that it follows RFC 4340 (section 6.6.1). Further, > | making this change should require little code change. > | > I like the solution introduced in patch #3 because it is simple: Change > options are retransmitted until the correct Confirm option comes in, > instead of resetting the connection. It is an instance of the robustness > principle - the peer can send any outdated/reordered Confirm option. Patches #2 and 3 (and another patch I will send shortly) make the current method usable. Without them, NN feature negotiation in an ongoing connection causes the connection to be reset. However, I wouldn't consider them a fix for what I'm talking about here. The fact is that with the current code the sender thinks the receiver has the new value of the feature while the feature is being negotiated. Particularly for the Ack Ratio this can be confusing because the sender would interpret the acks from the receiver using the new ack ratio. The first half RTT of those would be from the old ack ratio. This would cause inappropriate changes in the congestion window/pipe except for appropriate byte counting which, I believe, mitigates that. It just seems to me that there should be a better way to do this; something that's clearer and easier to understand/debug. > I find it better / more robust to wait for such problems to surface and then > tackle them, rather than making the local state change dependent on the other > end. Doing this complicates processing since the other endpoint is out of local > control, hence we need to make assumptions that can break in practice > (e.g. that a client should reply within two RTTs, but there is a sudden jamming > on the wireless / ADSL, so that the reply comes in only after multiples of > seconds). That makes sense. After having run more tests, this issue doesn't seem to be causing any problems right now. I'm okay with waiting until this causes a problem to try to come up with a better solution. Samuel Jero Internetworking Research Group Ohio University
Attachment:
signature.asc
Description: This is a digitally signed message part
