Subject: Re: [P2PSIP] ConfigUpdateReq flooding

From: "Michael Chen" <[email-masked]>
Date: Thu, 11 Aug 2011 21:58:32 -0700

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-masked]>
> Date: Tue, August 09, 2011 2:17 pm
> To: Michael Chen <[email-masked]>
> Cc: [email-masked]
> 
> 
> 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-masked]
> > https://www.ietf.org/mailman/listinfo/p2psip

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 12 Aug 2011 14:51:29 -0700

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.