perfsonar-dev - nmwg: r292 - trunk/nmwg/doc/dLS
Subject: perfsonar development work
List archive
- From:
- To: ,
- Subject: nmwg: r292 - trunk/nmwg/doc/dLS
- Date: Wed, 17 Oct 2007 10:03:16 -0400
Author: mac
Date: 2007-10-17 10:03:15 -0400 (Wed, 17 Oct 2007)
New Revision: 292
Modified:
trunk/nmwg/doc/dLS/dLS.html
trunk/nmwg/doc/dLS/dLS.pdf
trunk/nmwg/doc/dLS/dLS.xml
Log:
A few changes and comments. I will send an email with some concerns as well.
Modified: trunk/nmwg/doc/dLS/dLS.html
===================================================================
--- trunk/nmwg/doc/dLS/dLS.html 2007-10-17 10:39:20 UTC (rev 291)
+++ trunk/nmwg/doc/dLS/dLS.html 2007-10-17 14:03:15 UTC (rev 292)
@@ -428,10 +428,8 @@
</div>
<div id="rfc.figure.2">
</div>
-<p>HLS Cloud</p>
+<p>Token passing between HLS cloud</p>
<pre>
-
-A) Token passing
_____ _____
| | | |
| LS1 | <----------------- | LS2 |
@@ -442,8 +440,15 @@
| | | |
|-------> | LS3 | ---------|
|_____|
-
-B) Broadcast summary
+ </pre>
+<p>HLS instances communicating via a token message</p>
+<p class="figure">Figure 2</p>
+<div id="hls-cloud1">
+</div>
+<div id="rfc.figure.3">
+</div>
+<p>Broadcast summary</p>
+<pre>
_____ _____
| | | |
| LS1 | < > | LS2 |
@@ -457,9 +462,9 @@
\_/
</pre>
-<p>HLS instances communicating via a token message (A). The holder of the
token (LS3) will inform everyone of it's summary information (B).</p>
-<p class="figure">Figure 2</p>
-<p id="rfc.section.2.2.1.p.6">Once exchanged, the details regarding storage
in the XML database backend (see <a href="#glossary"
title="Glossary">Section 6.1</a>) are also left to individual
implementations. It is understood that this information, in the possession of
non HLS instances, is provided as a convenience and should be treated in the
same way that directly registered information is (i.e. purged on expiration).
When requested, credit must also be attributed to the HLS as being
(non)authoritative for each piece of information.</p>
+<p>The holder of the token (LS3) will inform everyone of its summary
information.</p>
+<p class="figure">Figure 3</p>
+<p id="rfc.section.2.2.1.p.7">Once exchanged, the details regarding storage
in the XML database backend (see <a href="#glossary"
title="Glossary">Section 6.1</a>) are also left to individual
implementations. It is understood that this information, in the possession of
non HLS instances, is provided as a convenience and should be treated in the
same way that directly registered information is (i.e. purged on expiration).
When requested, credit must also be attributed to the HLS as being
(non)authoritative for each piece of information.</p>
<h3 id="rfc.section.2.2.2">
<a href="#rfc.section.2.2.2">2.2.2</a> <a
id="upper_scope_summarization" href="#upper_scope_summarization">Upper Scope
Summarization</a>
</h3>
@@ -504,7 +509,7 @@
</p>
<div id="join-example2">
</div>
-<div id="rfc.figure.3">
+<div id="rfc.figure.4">
</div>
<p>Illustration of LS Join Algorithm</p>
<pre>
@@ -527,7 +532,7 @@
</pre>
<p>LS2, LS3 and LS4 are in the ring. LS1 wants to join the dLS cloud.</p>
-<p class="figure">Figure 3</p>
+<p class="figure">Figure 4</p>
<p> <p id="rfc.section.2.3.1.1.p.2">The algorithm for joining the ring
works as follows:</p> </p>
<dl class="empty">
<dd>1. LS1 - Candidate sends LSControlRequest message with the
http://perfsonar.net/services/LS/join eventType to selected LS2 which is
already a member of the ring. LS2 was found in LSRing initial file during
bootstrapping process.</dd>
@@ -554,7 +559,7 @@
</h4>
<div id="join-example">
</div>
-<div id="rfc.figure.4">
+<div id="rfc.figure.5">
</div>
<p>Illustration of Token Passing Algorithm</p>
<pre>
@@ -577,16 +582,22 @@
</pre>
<p>LS1, LS2 and LS3 are in the ring. LS1 receives a token.</p>
-<p class="figure">Figure 4</p>
+<p class="figure">Figure 5</p>
<p id="rfc.section.2.3.2.1.p.2">The algorithm for token passing works as
follows:</p>
<dl class="empty">
<dd>1. LS1 receives the token i.e. LSControlRequest message with the
http://perfsonar.net/services/LS/token/ eventType from its predecessor
L3.</dd>
<dd>2. LS1 updates its local peer list based on token content.</dd>
+<dd>2.x (More description needed)</dd>
+<dd>2.1 If token contains entry that is not present in the local LSRing,
copy this entry to local LSRing</dd>
+<dd>2.2 If token doesn't contains entry that is present in the local
LSRing... (to be discussed: there are two cases: new LS just joined to LS
that has got the token right now OR local LSRing contains obsolete LS entry
-- I guess we'll base on active parameter, but it's not elaborated how it
works</dd>
<dd>3. LS1 sends LSControlRequest message with the
http://perfsonar.net/services/LS/summary/ eventType to all peers in the lease
(excluding itself).</dd>
<dd>3. LS2 receiving this message checks its collection and updates it if
necessary with service info including "contentSize".</dd>
<dd>4. LS1 waits for some amount of time.</dd>
<dd>5. LS1 sends token to next LS (LS2) from the LSRing lower scope (if it
fails, try next one).</dd>
</dl>
+<h4 id="rfc.section.2.3.2.2">
+<a href="#rfc.section.2.3.2.2">2.3.2.2</a> <a
id="rotation-time-computing" href="#rotation-time-computing">Token rotation
time computing</a>
+</h4>
<h3 id="rfc.section.2.3.3">
<a href="#rfc.section.2.3.3">2.3.3</a> <a id="summary-blast"
href="#summary-blast">Summarization Notification</a>
</h3>
@@ -605,24 +616,6 @@
<p id="rfc.section.2.3.4.p.2">The theory behind this choice of leader is
that unladen LS instances will not be as loaded processing requests and
responses from clients and other services, thus the choice to name them as
leaders is natural. An added feature of this criteria is that it becomes very
simple to designate a leader LS for a domain; simply deploy an LS instance
that does not accept registrations. This service will only serve in the role
of liaison to the upper level.</p>
<p id="rfc.section.2.3.4.p.3">All LS instances will have a complete view at
any given time (and updated over time) of the values of the "contentSize"
parameter for all peer LS instances in an LSRing. This ensures that the
"Leader" and "Vice-Leader" are always known. Explicit election is therefore
not required, and succession can pass between the two executives quickly.</p>
<p id="rfc.section.2.3.4.p.4">The Leader and Vice-Leader LS instances should
exchange messages (see <a href="#LSControl-Leader" title="LS Leader
Message">Section 4.8</a>) periodically to ensure that in the event of a
failure the lower level will still have a link to the upper level. A
Vice-Leader will be monitoring the time between successive communications
from the Leader to be sure it has not failed. In the event that it has, the
"Join" procedure will start to the upper level to keep the hierarchy
complete.</p>
-<p id="rfc.section.2.3.4.p.5">
-<br>
-<br>
-<br>START_NOTE (Maciej 10/3/07):<br>
-<br> Question: I am not convinced "contentSize" should be the only
criterion. When new LS joins the ring it may have empty database, but in some
time it'll get a lot of metadata. The mechanism of leader election bases on
that, so its quite important. If such LS will "update" its "contentSize"
value not all other LS-es may know about it immediately (token passing cycle)
and they may not have the same knowledge about the leader. I"d prefer more
deterministic way of leader election. <br>
-<br>END_NOTE:<br>
-<br>
-<br>
-</p>
-<p id="rfc.section.2.3.4.p.6">
-<br>
-<br>
-<br>START_NOTE (Jason 10/4/07):<br>
-<br> I have added some more reasoning behind this, as well as a pointer to
some literature from the Gnutella folks as to why this is a good method. I am
not in favor of something complex when calculating a leader; we must choose
something that everyone can figure out [instantly] so that the ring continues
to function even during times when bad things are happening. Everyone will be
able to see (at any given time) how much information someone has, and the
notion that an unburdened system should be given more work (as opposed to a
system that may be very busy with local queries yet chosen anyway based on
separate criteria) is very appealing. <br>
-<br>END_NOTE:<br>
-<br>
-<br>
-</p>
<h3 id="rfc.section.2.3.5">
<a href="#rfc.section.2.3.5">2.3.5</a> <a id="scopes"
href="#scopes">Scopes</a>
</h3>
@@ -687,7 +680,7 @@
<p id="rfc.section.4.1.p.1">Example of metadata describing information
collected and stored in Measurement Archive service</p>
<p id="rfc.section.4.1.p.2">
<pre>
-
+
<nmwg:metadata xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";
id="m_ale-netutil-1">
<netutil:subject
xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/";
id="s_ale-netutil-1">
<nmwgt:interface
xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/">
@@ -707,7 +700,7 @@
</nmwg:parameters>
</nmwg:metadata>
- </pre>
+ </pre>
</p>
<h2 id="rfc.section.4.2">
<a href="#rfc.section.4.2">4.2</a> <a id="lookup-info"
href="#lookup-info">Lookup Information</a>
@@ -715,7 +708,7 @@
<p id="rfc.section.4.2.p.1">Example Lookup Information of Measurement
Archive. The metadata block contains basic service information and data
elements containing the metadata from the MA.</p>
<p id="rfc.section.4.2.p.2">
<pre>
-
+
<nmwg:metadata
id="http://newcastle.pc.cis.udel.edu:6767/perfSONAR_PS/services/snmpMA">
<perfsonar:subject id="subject.15977808">
<psservice:service id="service.16283379">
@@ -750,7 +743,7 @@
</nmwg:data>
- </pre>
+ </pre>
</p>
<h2 id="rfc.section.4.3">
<a href="#rfc.section.4.3">4.3</a> <a id="LSRing" href="#LSRing">LS
Ring File Structure</a>
@@ -762,7 +755,7 @@
</h3>
<p id="rfc.section.4.3.1.p.1">
<pre>
-
+
<nmwg:store type="LSRing-lower">
<!-- dont store yourself... -->
@@ -829,14 +822,14 @@
</nmwg:store>
- </pre>
+ </pre>
</p>
<h3 id="rfc.section.4.3.2">
<a href="#rfc.section.4.3.2">4.3.2</a> <a id="LSRingUpper"
href="#LSRingUpper">LS Ring upper level</a>
</h3>
<p id="rfc.section.4.3.2.p.1">
<pre>
-
+
<nmwg:store type="LSRing-upper">
<!-- dont store yourself... -->
@@ -873,7 +866,7 @@
</nmwg:store>
- </pre>
+ </pre>
</p>
<h2 id="rfc.section.4.4">
<a href="#rfc.section.4.4">4.4</a> <a id="LSControl-Join"
href="#LSControl-Join">LS Joining Message for Joining a Ring</a>
@@ -885,7 +878,7 @@
</h3>
<p id="rfc.section.4.4.1.p.1">
<pre>
-
+
<nmwg:message type="LSControlRequest">
<nmwg:metadata id="metadata.2">
@@ -907,14 +900,14 @@
</nmwg:message>
- </pre>
+ </pre>
</p>
<h3 id="rfc.section.4.4.2">
<a href="#rfc.section.4.4.2">4.4.2</a> <a id="LSControl-JoinResponse"
href="#LSControl-JoinResponse">Response</a>
</h3>
<p id="rfc.section.4.4.2.p.1">
<pre>
-
+
<nmwg:message type="LSControlResponse">
<nmwg:metadata id="metadata.6">
@@ -964,7 +957,7 @@
</nmwg:message>
- </pre>
+ </pre>
</p>
<h2 id="rfc.section.4.5">
<a href="#rfc.section.4.5">4.5</a> <a id="LSControl-Token"
href="#LSControl-Token">LS Token Message</a>
@@ -976,7 +969,7 @@
</h3>
<p id="rfc.section.4.5.1.p.1">
<pre>
-
+
<nmwg:message type="LSControlRequest">
<nmwg:metadata id="metadata.6">
@@ -1023,14 +1016,14 @@
</nmwg:message>
- </pre>
+ </pre>
</p>
<h3 id="rfc.section.4.5.2">
<a href="#rfc.section.4.5.2">4.5.2</a> <a id="LSControl-TokenResponse"
href="#LSControl-TokenResponse">Response</a>
</h3>
<p id="rfc.section.4.5.2.p.1">
<pre>
-
+
<nmwg:message type="LSControlResponse">
<nmwg:metadata id="metadata.2">
@@ -1055,7 +1048,7 @@
</nmwg:message>
- </pre>
+ </pre>
</p>
<h2 id="rfc.section.4.6">
<a href="#rfc.section.4.6">4.6</a> <a id="LSControl-Summary-lower"
href="#LSControl-Summary-lower">LS Summary Message (Lower)</a>
@@ -1073,7 +1066,7 @@
</h3>
<p id="rfc.section.4.6.1.p.1">
<pre>
-
+
<nmwg:message type="LSControlRequest">
<nmwg:metadata id="metadata.2">
@@ -1106,14 +1099,14 @@
</nmwg:message>
- </pre>
+ </pre>
</p>
<h3 id="rfc.section.4.6.2">
<a href="#rfc.section.4.6.2">4.6.2</a> <a
id="LSControl-Summary2Response"
href="#LSControl-Summary2Response">Response</a>
</h3>
<p id="rfc.section.4.6.2.p.1">
<pre>
-
+
<nmwg:message type="LSControlResponse">
<!-- whomever answers ... -->
@@ -1138,7 +1131,7 @@
</nmwg:message>
- </pre>
+ </pre>
</p>
<h2 id="rfc.section.4.7">
<a href="#rfc.section.4.7">4.7</a> <a id="LSControl-Summary-upper"
href="#LSControl-Summary-upper">LS Summary Message (Upper)</a>
@@ -1156,7 +1149,7 @@
</h3>
<p id="rfc.section.4.7.1.p.1">
<pre>
-
+
<nmwg:message type="LSControlRequest">
<nmwg:metadata id="metadata.2">
@@ -1204,14 +1197,14 @@
</nmwg:message>
- </pre>
+ </pre>
</p>
<h3 id="rfc.section.4.7.2">
<a href="#rfc.section.4.7.2">4.7.2</a> <a
id="LSControl-SummaryResponse" href="#LSControl-SummaryResponse">Response</a>
</h3>
<p id="rfc.section.4.7.2.p.1">
<pre>
-
+
<nmwg:message type="LSControlResponse">
<!-- whomever answers ... -->
@@ -1236,7 +1229,7 @@
</nmwg:message>
- </pre>
+ </pre>
</p>
<h2 id="rfc.section.4.8">
<a href="#rfc.section.4.8">4.8</a> <a id="LSControl-Leader"
href="#LSControl-Leader">LS Leader Message</a>
@@ -1248,7 +1241,7 @@
</h3>
<p id="rfc.section.4.8.1.p.1">
<pre>
-
+
<nmwg:message type="LSControlRequest">
<nmwg:metadata id="metadata.6">
@@ -1321,21 +1314,21 @@
</nmwg:message>
- </pre>
+ </pre>
</p>
<h3 id="rfc.section.4.8.2">
<a href="#rfc.section.4.8.2">4.8.2</a> <a id="LSControl-LeaderResponse"
href="#LSControl-LeaderResponse">Response</a>
</h3>
<p id="rfc.section.4.8.2.p.1">
<pre>
-
+
<nmwg:message type="LSControlRequest">
<!-- tbd -->
</nmwg:message>
- </pre>
+ </pre>
</p>
<h2 id="rfc.section.4.9">
<a href="#rfc.section.4.9">4.9</a> <a id="LSControl-Discovery"
href="#LSControl-Discovery">LS Discovery Message</a>
@@ -1346,7 +1339,7 @@
</h3>
<p id="rfc.section.4.9.1.p.1">
<pre>
-
+
<nmwg:message type="LSDiscoveryRequest">
<nmwg:metadata id="metadata.1">
@@ -1359,14 +1352,14 @@
</nmwg:message>
- </pre>
+ </pre>
</p>
<h3 id="rfc.section.4.9.2">
<a href="#rfc.section.4.9.2">4.9.2</a> <a id="LSDiscoveryResponse"
href="#LSDiscoveryResponse">Response</a>
</h3>
<p id="rfc.section.4.9.2.p.1">
<pre>
-
+
<nmwg:message type="LSDiscoveryResponse">
<nmwg:metadata id="metadata.1.r">
@@ -1399,7 +1392,7 @@
</nmwg:message>
- </pre>
+ </pre>
</p>
<hr class="noprint">
<h1 id="rfc.section.5" class="np">
Modified: trunk/nmwg/doc/dLS/dLS.pdf
===================================================================
(Binary files differ)
Modified: trunk/nmwg/doc/dLS/dLS.xml
===================================================================
--- trunk/nmwg/doc/dLS/dLS.xml 2007-10-17 10:39:20 UTC (rev 291)
+++ trunk/nmwg/doc/dLS/dLS.xml 2007-10-17 14:03:15 UTC (rev 292)
@@ -198,10 +198,8 @@
exchange to other known instances (see <xref target="glossary"
/>).
</t>
<figure anchor="hls-cloud">
- <preamble>HLS Cloud</preamble>
+ <preamble>Token passing between HLS cloud</preamble>
<artwork>
-
-A) Token passing
_____ _____
| | | |
| LS1 | <----------------- | LS2 |
@@ -212,8 +210,13 @@
| | | |
|-------> | LS3 | ---------|
|_____|
-
-B) Broadcast summary
+ </artwork>
+ <postamble>HLS instances communicating via a token
message</postamble>
+ </figure>
+
+ <figure anchor="hls-cloud1">
+ <preamble>Broadcast summary</preamble>
+ <artwork>
_____ _____
| | | |
| LS1 | < > | LS2 |
@@ -227,9 +230,8 @@
\_/
</artwork>
- <postamble>HLS instances communicating via a token message (A). The
- holder of the token (LS3) will inform everyone of
it's
- summary information (B).</postamble>
+ <postamble>The holder of the token (LS3) will inform everyone of its
+ summary information.</postamble>
</figure>
<t>Once exchanged, the details regarding storage in the XML database
backend (see <xref target="glossary" />) are also left to
@@ -577,6 +579,9 @@
with the http://perfsonar.net/services/LS/token/
eventType from its predecessor L3.</t>
<t>2. LS1 updates its local peer list based on token content.</t>
+ <t>2.x (More description needed)</t>
+ <t>2.1 If token contains entry that is not present in the local
LSRing, copy this entry to local LSRing</t>
+ <t>2.2 If token doesn't contains entry that is present in the local
LSRing... (to be discussed: there are two cases: new LS just joined to LS
that has got the token right now OR local LSRing contains obsolete LS entry
-- I guess we'll base on active parameter, but it's not elaborated how it
works</t>
<t>3. LS1 sends LSControlRequest message with the
http://perfsonar.net/services/LS/summary/ eventType
to all peers in the lease (excluding itself).</t>
@@ -587,6 +592,11 @@
(if it fails, try next one).</t>
</list>
</section>
+
+ <section anchor="rotation-time-computing" title="Token rotation time
computing">
+ The token rotation time is the time of passing and serving token by
all nodes in the LS ring. This time should be computed by the leader basing
on some knowledge about the time of serving token by all particular nodes.
The time may be based on times saving in token message by all nodes. (To be
discussed)
+ </section>
+
</section>
<section anchor="summary-blast" title="Summarization Notification">
<t>
@@ -662,6 +672,7 @@
it has, the "Join" procedure will start to the upper level to keep
the hierarchy complete.
</t>
+ <!--
<t>
<vspace blankLines="2" />START_NOTE (Maciej 10/3/07):<vspace
blankLines="1" />
Question: I am not convinced "contentSize" should be the only criterion.
@@ -685,6 +696,8 @@
local queries yet chosen anyway based on separate criteria) is very
appealing.
<vspace blankLines="1" />END_NOTE:<vspace blankLines="2" />
</t>
+-->
+
</section>
<section anchor="scopes" title="Scopes">
<t>Scopes are named based on URIs. The top-level domain provides a
- nmwg: r292 - trunk/nmwg/doc/dLS, svnlog, 10/17/2007
Archive powered by MHonArc 2.6.16.