Let's just make up some random numbers. Lets say that a config update happens once a month and most nodes are processing an average of 10 messages per second - with numbers like that, a 1 in 25 million messages causes a config update. That's why I called it a corner case but I agree, corner case is probably the wrong thing to call it - it is important even if it is rare.
There is nothing the forwarding nodes needs to do with any information in the configuration so it does not matter if it is out of date. But it is critical that the destination has the right config. So we said the destination MUST deal with this. If intermediate nodes choose to go load a new config after seeing theirs is out of date, I don't see any reason that would not be allowed but seems more like an implementation decision and an interoperability issue. It seems like some implementation would not want to do this as slowing down the 25 million messages outweighs the speeding up the 1 in 25 million case. Regardless of which way you do it, the new config floods across the overlay very quickly. On Aug 11, 2011, at 21:58 , Michael Chen wrote: > > I suppose the 0xffff sequence number is intended for force-feed a new > configuration to a handful of peers known to the configuration server > (although such method/policy is not spelled out by the draft). Beyond > that, section 5.3.2.1 (checking sequence number of a request) is the > only means defined by this draft to propagate new configuration > document. It's hardly a corner case. > > Am I missing something else? > > Thanks > > --Michael > >> -------- Original Message -------- >> Subject: Re: [P2PSIP] ConfigUpdateReq flooding >> From: Cullen Jennings <[email protected]> >> Date: Tue, August 09, 2011 2:17 pm >> To: Michael Chen <[email protected]> >> Cc: [email protected] >> >> >> The issue is we don't want to mandate that nodes that are purely forwarding >> a request have to check the config version. Theses nodes should be able to >> forward the request quickly without having to parse and interpret the whole >> request. In practice, when a new configuration files gets put out, it >> quickly floods the whole network so this is all pretty much a corner case. >> Making every message be checked would slow things down more than a message >> getting forwarded a few times before the destination node checked it in the >> rare case where there is a config update. Hope that makes sense - it's sort >> of hard to explain in email. >> >> >> On Aug 5, 2011, at 18:36 , Michael Chen wrote: >> >>> >>> Funny how one can understand his own question better afterward. This >>> topic stems from section 5.3.2.1 of the base draft, 2nd paragraph: >>> >>> "When a **destination** node receives a request, it MUST check that >>> the configuration_sequence field is equal to its own ..." >>> >>> Here are some possible interpretations: >>> >>> 1) The phrase "destination node" seems to suggest that only the >>> "ultimate" destination peer (whom the message was meant for) should >>> check/respond/update an out-dated configuration_sequence. >>> >>> 2) An intermediate peer should forward a knowingly out-dated >>> configuration_sequence number in the forwarding header. Section 5.3.2 >>> does not say that this field should be replaced in every hop. >>> >>> I suggest removing the word "destination" from the above paragraph and >>> make it clear that any request with an out-dated configuration_sequence >>> will never go beyond its first hop (immediate neighbor). >>> >>> Thanks >>> >>> --Michael >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
