Changing verification text to reflect changes in thought #1
Conversation
So this has a couple of edits, first it changes the verification selection process such that we chose routes we are *not* using because it's been generally agreed that routes we are using may as well be verified continuously. This also changes some of the wording of the selection method to be more rigorous by stating that we intend a simple random sample. As opposed to other possible sampling methods, some of which may even have advantages for us if significant effort was invested in utilizing them well (clustered samples for example could help narrow down sources of inaccuracy). As a final note it might be useful to look into how many routes a given node must sample for a given routing table size in order for every route advertised to be verified within some reasonable period and confidence interval.
| @@ -170,18 +170,20 @@ \subsection{Route metric verification} | |||
|
|
|||
| \subsection{Verification scheduling} | |||
| \begin{unbreakable} | |||
| We have the ability to test and verify the routes advertised by neighbors, but we need some way of deciding which routes to verify. Verification runs on a timer. Each verification cycle a node follows this procedure to choose a route $r$ to verify: | |||
| We have the ability to test and verify the routes advertised by neighbors, and once we have connections open to endpoints we are already using piggybacking packets to verify already used connections is trivial and can be done continuously to prevent fraud. But we would also like to avoid participating in the advertisement of false routes unkowningly. Therefore we need some way of deciding routes to verify from the set of routes in the local routing table we are not currently using. | |||
There was a problem hiding this comment.
Do you still want to make this change?
There was a problem hiding this comment.
I think this more closely reflects what we actually plan to do. So I guess that's a yes.
There was a problem hiding this comment.
I think this is incomplete, since the next sentence in the paper is: "We start with the set of all destinations that have been used in the past x seconds." This would appear to contradict "Therefore we need some way of deciding routes to verify from the set of routes in the local routing table we are not currently using.", since the procedure deals with the selection of destinations to verify from the set of destinations that have been used in the past x seconds (I would consider this set to be "currently used" for all intents and purposes, since a "connection" on a higher level will not be sending data continuously).
Maybe we should change this in some way, and you'll probably be coding it so it's up to you, but it needs to be more fully specified IMO.
So this has a couple of edits, first it changes the verification selection
process such that we chose routes we are not using because it's been
generally agreed that routes we are using may as well be verified continuously.
This also changes some of the wording of the selection method to be more
rigorous by stating that we intend a simple random sample. As opposed to other
possible sampling methods, some of which may even have advantages for us if
significant effort was invested in utilizing them well (clustered samples for
example could help narrow down sources of inaccuracy).
As a final note it might be useful to look into how many routes a given node
must sample for a given routing table size in order for every route advertised
to be verified within some reasonable period and confidence interval.