SoutheastCon2024
This commit is contained in:
parent
edc111f5d0
commit
95d748f279
BIN
SoutheastCon/Original Submission/AG-CG-CR_blind.pdf
Normal file
BIN
SoutheastCon/Original Submission/AG-CG-CR_blind.pdf
Normal file
Binary file not shown.
221
SoutheastCon/Original Submission/Bibliography.bib
Normal file
221
SoutheastCon/Original Submission/Bibliography.bib
Normal file
@ -0,0 +1,221 @@
|
||||
@inproceedings{CR-Simple,
|
||||
author = {Nosayba El{-}Sayed and
|
||||
Bianca Schroeder},
|
||||
title = {Checkpoint/restart in practice: When 'simple is better'},
|
||||
booktitle = {2014 {IEEE} International Conference on Cluster Computing, {CLUSTER}
|
||||
2014, Madrid, Spain, September 22-26, 2014},
|
||||
pages = {84--92},
|
||||
publisher = {{IEEE} Computer Society},
|
||||
year = {2014},
|
||||
url = {https://doi.org/10.1109/CLUSTER.2014.6968777},
|
||||
doi = {10.1109/CLUSTER.2014.6968777},
|
||||
timestamp = {Thu, 23 Mar 2023 23:59:40 +0100},
|
||||
biburl = {https://dblp.org/rec/conf/cluster/El-SayedS14.bib},
|
||||
bibsource = {dblp computer science bibliography, https://dblp.org}
|
||||
}
|
||||
|
||||
@ARTICLE{7087377,
|
||||
author={Kaynar, Kerem and Sivrikaya, Fikret},
|
||||
journal={IEEE Transactions on Dependable and Secure Computing},
|
||||
title={Distributed Attack Graph Generation},
|
||||
year={2016},
|
||||
volume={13},
|
||||
number={5},
|
||||
pages={519-532},
|
||||
doi={10.1109/TDSC.2015.2423682}
|
||||
}
|
||||
|
||||
@INPROCEEDINGS{LAPA,
|
||||
author={Yi, Feng and Cai, Huang Yi and Xin, Fu Zheng},
|
||||
booktitle={2018 IEEE International Conference on Networking, Architecture and Storage (NAS)},
|
||||
title={A Logic-Based Attack Graph for Analyzing Network Security Risk Against Potential Attack},
|
||||
year={2018},
|
||||
volume={},
|
||||
number={},
|
||||
pages={1-4},
|
||||
doi={10.1109/NAS.2018.8515733}
|
||||
}
|
||||
|
||||
@INPROCEEDINGS{AG-Sample,
|
||||
author={Subasi, Omer and Purohit, Sumit and Bhattacharya, Arnab and Chatterjee, Samrat},
|
||||
booktitle={2022 IEEE International Symposium on Technologies for Homeland Security (HST)},
|
||||
title={Impact-Driven Sampling Strategies for Hybrid Attack Graphs},
|
||||
year={2022},
|
||||
volume={},
|
||||
number={},
|
||||
pages={1-7},
|
||||
doi={10.1109/HST56032.2022.10025439}
|
||||
}
|
||||
|
||||
|
||||
@INPROCEEDINGS{GraphDB,
|
||||
author={Simon-Nagy, Gabriella and Fleiner, Rita and Bánáti, Anna},
|
||||
booktitle={2022 IEEE 20th Jubilee International Symposium on Intelligent Systems and Informatics (SISY)},
|
||||
title={Attack Graph Implementation in Graph Database},
|
||||
year={2022},
|
||||
volume={},
|
||||
number={},
|
||||
pages={000127-000132},
|
||||
doi={10.1109/SISY56759.2022.10036309}
|
||||
}
|
||||
|
||||
@INPROCEEDINGS{Graph-DB,
|
||||
author={Yuan, Bintao and Pan, Zulie and Shi, Fan and Li, Zhenhan},
|
||||
booktitle={2020 IEEE 4th Information Technology, Networking, Electronic and Automation Control Conference (ITNEC)},
|
||||
title={An Attack Path Generation Methods Based on Graph Database},
|
||||
year={2020},
|
||||
volume={1},
|
||||
number={},
|
||||
pages={1905-1910},
|
||||
doi={10.1109/ITNEC48623.2020.9085039}
|
||||
}
|
||||
|
||||
|
||||
@book{hursey2010coordinated,
|
||||
title={Coordinated checkpoint/restart process fault tolerance for MPI applications on HPC systems},
|
||||
author={Hursey, Joshua},
|
||||
year={2010},
|
||||
publisher={Indiana University}
|
||||
}
|
||||
|
||||
@misc{dmtcp,
|
||||
title={DMTCP: Transparent Checkpointing for Cluster Computations and the Desktop},
|
||||
author={Jason Ansel and Kapil Arya and Gene Cooperman},
|
||||
year={2009},
|
||||
eprint={cs/0701037},
|
||||
archivePrefix={arXiv},
|
||||
primaryClass={cs.DC}
|
||||
}
|
||||
|
||||
@article{BLCR,
|
||||
title = {Requirements for Linux Checkpoint/Restart},
|
||||
author = {Duell, Jason and Hargrove, Paul H and Roman, Eric S},
|
||||
doi = {10.2172/793773},
|
||||
url = {https://www.osti.gov/biblio/793773},
|
||||
place = {United States},
|
||||
year = {2002},
|
||||
month = {2}
|
||||
}
|
||||
|
||||
@INPROCEEDINGS{CR-Survey,
|
||||
author={Shahzad, Faisal and Wittmann, Markus and Zeiser, Thomas and Hager, Georg and Wellein, Gerhard},
|
||||
booktitle={2013 IEEE International Symposium on Parallel and Distributed Processing, Workshops and Phd Forum},
|
||||
title={An Evaluation of Different I/O Techniques for Checkpoint/Restart},
|
||||
year={2013},
|
||||
pages={1708-1716},
|
||||
doi={10.1109/IPDPSW.2013.145}
|
||||
}
|
||||
|
||||
@INPROCEEDINGS{SCR,
|
||||
author={Moody, Adam and Bronevetsky, Greg and Mohror, Kathryn and Supinski, Bronis R. de},
|
||||
booktitle={SC '10: Proceedings of the 2010 ACM/IEEE International Conference for High Performance Computing, Networking, Storage and Analysis},
|
||||
title={Design, Modeling, and Evaluation of a Scalable Multi-level Checkpointing System},
|
||||
year={2010},
|
||||
pages={1-11},
|
||||
doi={10.1109/SC.2010.18}
|
||||
}
|
||||
|
||||
@article{ainsworth_graph_2016,
|
||||
title = {Graph prefetching using data structure knowledge},
|
||||
volume = {01-03-June},
|
||||
issn = {9781450343619},
|
||||
doi = {10.1145/2925426.2926254},
|
||||
journal = {Proceedings of the International Conference on Supercomputing},
|
||||
author = {Ainsworth, Sam and Jones, Timothy M.},
|
||||
year = {2016},
|
||||
keywords = {Graphs, Prefetching},
|
||||
}
|
||||
|
||||
@article{berry_graph_2007,
|
||||
title = {Graph {Analysis} with {High} {Performance} {Computing}.},
|
||||
journal = {Computing in Science and Engineering},
|
||||
author = {Berry, Jonathan and Hendrickson, Bruce},
|
||||
year = {2007},
|
||||
file = {Graph Analysis With High-Performance Computing:/home/noah/Zotero/storage/T84DCNCC/Graph Analysis With High-Performance Computing.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@mastersthesis{cook_rage_2018,
|
||||
title = {{RAGE}: {The} {Rage} {Attack} {Graph} {Engine}},
|
||||
author = {Cook, Kyle},
|
||||
school = {The {University} of {Tulsa}},
|
||||
year = {2018},
|
||||
file = {Kyle Cook Thesis:/home/noah/Zotero/storage/2SR28HM2/Kyle Cook Thesis.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@article{cook_scalable_2016,
|
||||
title = {Scalable attack graph generation},
|
||||
issn = {9781450337526},
|
||||
doi = {10.1145/2897795.2897821},
|
||||
abstract = {Attack graphs are a powerful modeling technique with which to explore the attack surface of a system. However, they can be difficult to generate due to the exponential growth of the state space, often times making exhaustive search im- practical. This paper discusses an approach for generating large attack graphs with an emphasis on scalable generation over a distributed system. First, a serial algorithm is presented, highlighting bottlenecks and opportunities to exploit inherent concurrency in the generation process. Then a strategy to parallelize this process is presented. Finally, we discuss plans for future work to implement the parallel algorithm using a hybrid distributed/shared memory programming model on a heterogeneous compute node cluster.},
|
||||
journal = {Proceedings of the 11th Annual Cyber and Information Security Research Conference, CISRC 2016},
|
||||
author = {Cook, Kyle and Shaw, Thomas and Hale, John and Hawrylak, Peter},
|
||||
year = {2016},
|
||||
keywords = {Attack graphs, Attack modeling, Vulnerability analysis},
|
||||
file = {Attachment:/home/noah/Zotero/storage/2YNSLTQH/Scalable Attack Graph Generation:application/pdf},
|
||||
}
|
||||
|
||||
@misc{j_hale_compliance_nodate,
|
||||
title = {Compliance {Method} for a {Cyber}-{Physical} {System}},
|
||||
author = {{J. Hale} and Hawrylak, P. and Papa, M.},
|
||||
note = {U.S. Patent Number 9,471,789, Oct. 18, 2016.},
|
||||
number = {9471789},
|
||||
file = {Complaince_Graph_US_Patent_9471789:/home/noah/Zotero/storage/55BZN4U7/Complaince_Graph_US_Patent_9471789.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@article{li_combining_2019,
|
||||
title = {Combining {OpenCL} and {MPI} to support heterogeneous computing on a cluster},
|
||||
issn = {9781450372275},
|
||||
doi = {10.1145/3332186.3333059},
|
||||
abstract = {This paper presents an implementation of a heterogeneous programming model which combines Open Computing Language (OpenCL) and Message Passing Interface (MPI). The model is applied to solving a Markov decision process (MDP) with value iteration method. The performance test is conducted on a high performance computing cluster. At peak performance, the model is able to achieve a 57X speedup over a serial implementation. For an extremely large input MDP, which has 1,000,000 states, the obtained speedup is still over 12X, showing that this heterogeneous programming model can solve MDPs more efficiently than the serial solver does.},
|
||||
journal = {ACM International Conference Proceeding Series},
|
||||
author = {Li, Ming and Hawrylak, Peter and Hale, John},
|
||||
year = {2019},
|
||||
keywords = {Heterogeneous computing, HPC, MDP, MPI, OpenCL, Parallelism},
|
||||
file = {Combining OpenCL and MPI to Support Heterogeneous Computing on a Cluster:/home/noah/Zotero/storage/TXHCQ5S8/Combining OpenCL and MPI to Support Heterogeneous Computing on a Cluster.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@article{li_concurrency_2019,
|
||||
title = {Concurrency {Strategies} for {Attack} {Graph} {Generation}},
|
||||
issn = {9781728120805},
|
||||
doi = {10.1109/ICDIS.2019.00033},
|
||||
abstract = {The network attack graph is a powerful tool for analyzing network security, but the generation of a large-scale graph is non-trivial. The main challenge is from the explosion of network state space, which greatly increases time and storage costs. In this paper, three parallel algorithms are proposed to generate scalable attack graphs. An OpenMP-based programming implementation is used to test their performance. Compared with the serial algorithm, the best performance from the proposed algorithms provides a 10X speedup.},
|
||||
journal = {Proceedings - 2019 2nd International Conference on Data Intelligence and Security, ICDIS 2019},
|
||||
author = {Li, Ming and Hawrylak, Peter and Hale, John},
|
||||
year = {2019},
|
||||
keywords = {Attack Graph, Multi-threaded Programming, Network Security, OpenMP},
|
||||
pages = {174--179},
|
||||
file = {Ming_LI_Thesis:/home/noah/Zotero/storage/CLSLS335/Ming_LI_Thesis.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@article{ou_scalable_2006,
|
||||
title = {A {Scalable} {Approach} to {Attack} {Graph} {Generation}},
|
||||
issn = {1595935185},
|
||||
author = {Ou, Xinming and Boyer, Wayne F and Mcqueen, Miles A},
|
||||
year = {2006},
|
||||
journal = {CCS '06: Proceedings of the 13th ACM conference on Computer and communications security},
|
||||
keywords = {attack graphs, enterprise network security, logic-programming},
|
||||
pages = {336--345},
|
||||
file = {1180405.1180446:/home/noah/Zotero/storage/TJKHVC4R/1180405.1180446.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@article{schneier_modeling_1999,
|
||||
title = {Modeling {Security} {Threats}},
|
||||
url = {https://www.schneier.com/academic/archives/1999/12/attack_trees.html},
|
||||
author = {Schneier, Bruce},
|
||||
year = {1999},
|
||||
journal = {Dr. Dobb's Journal},
|
||||
note = {vol. 24, no.12}
|
||||
}
|
||||
|
||||
@article{zhang_boosting_2017,
|
||||
title = {Boosting the performance of {FPGA}-based graph processor using hybrid memory cube: {A} case for breadth first search},
|
||||
issn = {9781450343541},
|
||||
doi = {10.1145/3020078.3021737},
|
||||
abstract = {Large graph processing has gained great attention in recent years due to its broad applicability from machine learning to social science. Large real-world graphs, however, are inherently difficult to process efficiently, not only due to their large memory footprint, but also that most graph algorithms entail memory access patterns with poor locality and a low compute-to-memory access ratio. In this work, we leverage the exceptional random access performance of emerging Hybrid Memory Cube (HMC) technology that stacks multiple DRAM dies on top of a logic layer, combined with the flexibility and efficiency of FPGA to address these challenges. To our best knowledge, this is the first work that implements a graph processing system on a FPGA-HMC platform based on software/hardware co-design and co-optimization. We first present the modifications of algorithm and a platform-aware graph processing architecture to perform level-synchronized breadth first search (BFS) on FPGA-HMC platform. To gain better insights into the potential bottlenecks of proposed implementation, we develop an analytical performance model to quantitatively evaluate the HMC access latency and corresponding BFS performance. Based on the analysis, we propose a two-level bitmap scheme to further reduce memory access and perform optimization on key design parameters (e.g. memory access granularity). Finally, we evaluate the performance of our BFS implementation using the AC-510 development kit from Micron. We achieved 166 million edges traversed per second (MTEPS) using GRAPH500 benchmark on a random graph with a scale of 25 and an edge factor of 16, which significantly outperforms CPU and other FPGA-based large graph processors.},
|
||||
journal = {FPGA 2017 - Proceedings of the 2017 ACM/SIGDA International Symposium on Field-Programmable Gate Arrays},
|
||||
author = {Zhang, Jialiang and Khoram, Soroosh and Li, Jing},
|
||||
year = {2017},
|
||||
pages = {207--216},
|
||||
file = {Boosting the Performance of FPGA-based Graph Processor using Hybrdi Memory Cube:/home/noah/Zotero/storage/CDKPUXYF/Boosting the Performance of FPGA-based Graph Processor using Hybrdi Memory Cube.pdf:application/pdf},
|
||||
}
|
||||
|
||||
80
SoutheastCon/Original Submission/Schrick-Noah_AG-CG-CR.aux
Normal file
80
SoutheastCon/Original Submission/Schrick-Noah_AG-CG-CR.aux
Normal file
@ -0,0 +1,80 @@
|
||||
\relax
|
||||
\providecommand\babel@aux[2]{}
|
||||
\@nameuse{bbl@beforestart}
|
||||
\citation{schneier_modeling_1999}
|
||||
\citation{j_hale_compliance_nodate}
|
||||
\citation{cook_rage_2018}
|
||||
\citation{berry_graph_2007}
|
||||
\citation{berry_graph_2007}
|
||||
\citation{zhang_boosting_2017}
|
||||
\citation{ainsworth_graph_2016}
|
||||
\citation{berry_graph_2007}
|
||||
\citation{ainsworth_graph_2016}
|
||||
\citation{cook_rage_2018}
|
||||
\citation{cook_rage_2018}
|
||||
\citation{ou_scalable_2006}
|
||||
\citation{CR-Survey}
|
||||
\citation{hursey2010coordinated}
|
||||
\citation{SCR}
|
||||
\citation{dmtcp}
|
||||
\citation{BLCR}
|
||||
\babel@aux{nil}{}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {I}Introduction}{1}{}\protected@file@percent }
|
||||
\newlabel{sec:Intro}{{I}{1}}
|
||||
\citation{GraphDB}
|
||||
\citation{Graph-DB}
|
||||
\citation{ou_scalable_2006}
|
||||
\citation{LAPA}
|
||||
\citation{cook_scalable_2016}
|
||||
\citation{li_concurrency_2019}
|
||||
\citation{AG-Sample}
|
||||
\citation{7087377}
|
||||
\citation{cook_rage_2018}
|
||||
\citation{li_concurrency_2019}
|
||||
\citation{li_combining_2019}
|
||||
\citation{zhang_boosting_2017}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {II}Related Work}{2}{}\protected@file@percent }
|
||||
\newlabel{sec:Rel-Works}{{II}{2}}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {III}Methodology}{2}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-A}}Checkpointing}{2}{}\protected@file@percent }
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces An Attack or Compliance Graph Undergoing Generation}}{2}{}\protected@file@percent }
|
||||
\newlabel{fig:cr}{{1}{2}}
|
||||
\newlabel{sec:mem-constraint}{{\mbox {III-A}1}{2}}
|
||||
\@writefile{toc}{\contentsline {subsubsection}{\numberline {\mbox {III-A}1}Memory Constraint Difficulties}{2}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsubsection}{\numberline {\mbox {III-A}2}Implementation}{2}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsubsection}{\numberline {\mbox {III-A}3}Portability}{3}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {III-B}}Restarting}{3}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {IV}Results}{3}{}\protected@file@percent }
|
||||
\citation{CR-Simple}
|
||||
\bibdata{Bibliography}
|
||||
\bibcite{schneier_modeling_1999}{1}
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Time Taken to Checkpoint as the Size of the Instance Grows}}{4}{}\protected@file@percent }
|
||||
\newlabel{fig:inst-time}{{2}{4}}
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {3}{\ignorespaces Time Taken to Checkpoint as the Size of the Frontier Grows}}{4}{}\protected@file@percent }
|
||||
\newlabel{fig:front-chk-time}{{3}{4}}
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {4}{\ignorespaces Time Taken to Restart as the Size of the Frontier Grows}}{4}{}\protected@file@percent }
|
||||
\newlabel{fig:front-rest-time}{{4}{4}}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {V}Conclusions and Future Work}{4}{}\protected@file@percent }
|
||||
\bibcite{j_hale_compliance_nodate}{2}
|
||||
\bibcite{cook_rage_2018}{3}
|
||||
\bibcite{berry_graph_2007}{4}
|
||||
\bibcite{zhang_boosting_2017}{5}
|
||||
\bibcite{ainsworth_graph_2016}{6}
|
||||
\bibcite{ou_scalable_2006}{7}
|
||||
\bibcite{CR-Survey}{8}
|
||||
\bibcite{hursey2010coordinated}{9}
|
||||
\bibcite{SCR}{10}
|
||||
\bibcite{dmtcp}{11}
|
||||
\bibcite{BLCR}{12}
|
||||
\bibcite{GraphDB}{13}
|
||||
\bibcite{Graph-DB}{14}
|
||||
\bibcite{LAPA}{15}
|
||||
\bibcite{cook_scalable_2016}{16}
|
||||
\bibcite{li_concurrency_2019}{17}
|
||||
\bibcite{AG-Sample}{18}
|
||||
\bibcite{7087377}{19}
|
||||
\bibcite{li_combining_2019}{20}
|
||||
\bibcite{CR-Simple}{21}
|
||||
\bibstyle{ieeetr}
|
||||
\@writefile{toc}{\contentsline {section}{References}{5}{}\protected@file@percent }
|
||||
\gdef \@abspage@last{5}
|
||||
110
SoutheastCon/Original Submission/Schrick-Noah_AG-CG-CR.bbl
Normal file
110
SoutheastCon/Original Submission/Schrick-Noah_AG-CG-CR.bbl
Normal file
@ -0,0 +1,110 @@
|
||||
\begin{thebibliography}{10}
|
||||
|
||||
\bibitem{schneier_modeling_1999}
|
||||
B.~Schneier, ``Modeling {Security} {Threats},'' {\em Dr. Dobb's Journal}, 1999.
|
||||
\newblock vol. 24, no.12.
|
||||
|
||||
\bibitem{j_hale_compliance_nodate}
|
||||
{J. Hale}, P.~Hawrylak, and M.~Papa, ``Compliance {Method} for a
|
||||
{Cyber}-{Physical} {System}.''
|
||||
\newblock U.S. Patent Number 9,471,789, Oct. 18, 2016.
|
||||
|
||||
\bibitem{cook_rage_2018}
|
||||
K.~Cook, ``{RAGE}: {The} {Rage} {Attack} {Graph} {Engine},'' Master's thesis,
|
||||
The {University} of {Tulsa}, 2018.
|
||||
|
||||
\bibitem{berry_graph_2007}
|
||||
J.~Berry and B.~Hendrickson, ``Graph {Analysis} with {High} {Performance}
|
||||
{Computing}.,'' {\em Computing in Science and Engineering}, 2007.
|
||||
|
||||
\bibitem{zhang_boosting_2017}
|
||||
J.~Zhang, S.~Khoram, and J.~Li, ``Boosting the performance of {FPGA}-based
|
||||
graph processor using hybrid memory cube: {A} case for breadth first
|
||||
search,'' {\em FPGA 2017 - Proceedings of the 2017 ACM/SIGDA International
|
||||
Symposium on Field-Programmable Gate Arrays}, pp.~207--216, 2017.
|
||||
|
||||
\bibitem{ainsworth_graph_2016}
|
||||
S.~Ainsworth and T.~M. Jones, ``Graph prefetching using data structure
|
||||
knowledge,'' {\em Proceedings of the International Conference on
|
||||
Supercomputing}, vol.~01-03-June, 2016.
|
||||
|
||||
\bibitem{ou_scalable_2006}
|
||||
X.~Ou, W.~F. Boyer, and M.~A. Mcqueen, ``A {Scalable} {Approach} to {Attack}
|
||||
{Graph} {Generation},'' {\em CCS '06: Proceedings of the 13th ACM conference
|
||||
on Computer and communications security}, pp.~336--345, 2006.
|
||||
|
||||
\bibitem{CR-Survey}
|
||||
F.~Shahzad, M.~Wittmann, T.~Zeiser, G.~Hager, and G.~Wellein, ``An evaluation
|
||||
of different i/o techniques for checkpoint/restart,'' in {\em 2013 IEEE
|
||||
International Symposium on Parallel and Distributed Processing, Workshops and
|
||||
Phd Forum}, pp.~1708--1716, 2013.
|
||||
|
||||
\bibitem{hursey2010coordinated}
|
||||
J.~Hursey, {\em Coordinated checkpoint/restart process fault tolerance for MPI
|
||||
applications on HPC systems}.
|
||||
\newblock Indiana University, 2010.
|
||||
|
||||
\bibitem{SCR}
|
||||
A.~Moody, G.~Bronevetsky, K.~Mohror, and B.~R.~d. Supinski, ``Design, modeling,
|
||||
and evaluation of a scalable multi-level checkpointing system,'' in {\em SC
|
||||
'10: Proceedings of the 2010 ACM/IEEE International Conference for High
|
||||
Performance Computing, Networking, Storage and Analysis}, pp.~1--11, 2010.
|
||||
|
||||
\bibitem{dmtcp}
|
||||
J.~Ansel, K.~Arya, and G.~Cooperman, ``Dmtcp: Transparent checkpointing for
|
||||
cluster computations and the desktop,'' 2009.
|
||||
|
||||
\bibitem{BLCR}
|
||||
J.~Duell, P.~H. Hargrove, and E.~S. Roman, ``Requirements for linux
|
||||
checkpoint/restart,'' 2 2002.
|
||||
|
||||
\bibitem{GraphDB}
|
||||
G.~Simon-Nagy, R.~Fleiner, and A.~Bánáti, ``Attack graph implementation in
|
||||
graph database,'' in {\em 2022 IEEE 20th Jubilee International Symposium on
|
||||
Intelligent Systems and Informatics (SISY)}, pp.~000127--000132, 2022.
|
||||
|
||||
\bibitem{Graph-DB}
|
||||
B.~Yuan, Z.~Pan, F.~Shi, and Z.~Li, ``An attack path generation methods based
|
||||
on graph database,'' in {\em 2020 IEEE 4th Information Technology,
|
||||
Networking, Electronic and Automation Control Conference (ITNEC)}, vol.~1,
|
||||
pp.~1905--1910, 2020.
|
||||
|
||||
\bibitem{LAPA}
|
||||
F.~Yi, H.~Y. Cai, and F.~Z. Xin, ``A logic-based attack graph for analyzing
|
||||
network security risk against potential attack,'' in {\em 2018 IEEE
|
||||
International Conference on Networking, Architecture and Storage (NAS)},
|
||||
pp.~1--4, 2018.
|
||||
|
||||
\bibitem{cook_scalable_2016}
|
||||
K.~Cook, T.~Shaw, J.~Hale, and P.~Hawrylak, ``Scalable attack graph
|
||||
generation,'' {\em Proceedings of the 11th Annual Cyber and Information
|
||||
Security Research Conference, CISRC 2016}, 2016.
|
||||
|
||||
\bibitem{li_concurrency_2019}
|
||||
M.~Li, P.~Hawrylak, and J.~Hale, ``Concurrency {Strategies} for {Attack}
|
||||
{Graph} {Generation},'' {\em Proceedings - 2019 2nd International Conference
|
||||
on Data Intelligence and Security, ICDIS 2019}, pp.~174--179, 2019.
|
||||
|
||||
\bibitem{AG-Sample}
|
||||
O.~Subasi, S.~Purohit, A.~Bhattacharya, and S.~Chatterjee, ``Impact-driven
|
||||
sampling strategies for hybrid attack graphs,'' in {\em 2022 IEEE
|
||||
International Symposium on Technologies for Homeland Security (HST)},
|
||||
pp.~1--7, 2022.
|
||||
|
||||
\bibitem{7087377}
|
||||
K.~Kaynar and F.~Sivrikaya, ``Distributed attack graph generation,'' {\em IEEE
|
||||
Transactions on Dependable and Secure Computing}, vol.~13, no.~5,
|
||||
pp.~519--532, 2016.
|
||||
|
||||
\bibitem{li_combining_2019}
|
||||
M.~Li, P.~Hawrylak, and J.~Hale, ``Combining {OpenCL} and {MPI} to support
|
||||
heterogeneous computing on a cluster,'' {\em ACM International Conference
|
||||
Proceeding Series}, 2019.
|
||||
|
||||
\bibitem{CR-Simple}
|
||||
N.~El{-}Sayed and B.~Schroeder, ``Checkpoint/restart in practice: When 'simple
|
||||
is better','' in {\em 2014 {IEEE} International Conference on Cluster
|
||||
Computing, {CLUSTER} 2014, Madrid, Spain, September 22-26, 2014}, pp.~84--92,
|
||||
{IEEE} Computer Society, 2014.
|
||||
|
||||
\end{thebibliography}
|
||||
48
SoutheastCon/Original Submission/Schrick-Noah_AG-CG-CR.blg
Normal file
48
SoutheastCon/Original Submission/Schrick-Noah_AG-CG-CR.blg
Normal file
@ -0,0 +1,48 @@
|
||||
This is BibTeX, Version 0.99d (TeX Live 2023/Arch Linux)
|
||||
Capacity: max_strings=200000, hash_size=200000, hash_prime=170003
|
||||
The top-level auxiliary file: Schrick-Noah_AG-CG-CR.aux
|
||||
The style file: ieeetr.bst
|
||||
Database file #1: Bibliography.bib
|
||||
Warning--empty journal in BLCR
|
||||
You've used 21 entries,
|
||||
1876 wiz_defined-function locations,
|
||||
596 strings with 7573 characters,
|
||||
and the built_in function-call counts, 5310 in all, are:
|
||||
= -- 495
|
||||
> -- 216
|
||||
< -- 0
|
||||
+ -- 80
|
||||
- -- 59
|
||||
* -- 347
|
||||
:= -- 749
|
||||
add.period$ -- 23
|
||||
call.type$ -- 21
|
||||
change.case$ -- 20
|
||||
chr.to.int$ -- 0
|
||||
cite$ -- 22
|
||||
duplicate$ -- 286
|
||||
empty$ -- 542
|
||||
format.name$ -- 59
|
||||
if$ -- 1310
|
||||
int.to.chr$ -- 0
|
||||
int.to.str$ -- 21
|
||||
missing$ -- 19
|
||||
newline$ -- 69
|
||||
num.names$ -- 21
|
||||
pop$ -- 103
|
||||
preamble$ -- 1
|
||||
purify$ -- 0
|
||||
quote$ -- 0
|
||||
skip$ -- 176
|
||||
stack$ -- 0
|
||||
substring$ -- 311
|
||||
swap$ -- 101
|
||||
text.length$ -- 0
|
||||
text.prefix$ -- 0
|
||||
top$ -- 0
|
||||
type$ -- 0
|
||||
warning$ -- 1
|
||||
while$ -- 47
|
||||
width$ -- 23
|
||||
write$ -- 188
|
||||
(There was 1 warning)
|
||||
476
SoutheastCon/Original Submission/Schrick-Noah_AG-CG-CR.log
Normal file
476
SoutheastCon/Original Submission/Schrick-Noah_AG-CG-CR.log
Normal file
@ -0,0 +1,476 @@
|
||||
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Arch Linux) (preloaded format=pdflatex 2023.9.6) 14 DEC 2023 13:17
|
||||
entering extended mode
|
||||
restricted \write18 enabled.
|
||||
%&-line parsing enabled.
|
||||
**Schrick-Noah_AG-CG-CR.tex
|
||||
(./Schrick-Noah_AG-CG-CR.tex
|
||||
LaTeX2e <2022-11-01> patch level 1
|
||||
L3 programming layer <2023-02-22>
|
||||
(/usr/share/texmf-dist/tex/latex/ieeetran/IEEEtran.cls
|
||||
Document Class: IEEEtran 2015/08/26 V1.8b by Michael Shell
|
||||
-- See the "IEEEtran_HOWTO" manual for usage information.
|
||||
-- http://www.michaelshell.org/tex/ieeetran/
|
||||
\@IEEEtrantmpdimenA=\dimen140
|
||||
\@IEEEtrantmpdimenB=\dimen141
|
||||
\@IEEEtrantmpdimenC=\dimen142
|
||||
\@IEEEtrantmpcountA=\count185
|
||||
\@IEEEtrantmpcountB=\count186
|
||||
\@IEEEtrantmpcountC=\count187
|
||||
\@IEEEtrantmptoksA=\toks16
|
||||
LaTeX Font Info: Trying to load font information for OT1+ptm on input line 5
|
||||
03.
|
||||
(/usr/share/texmf-dist/tex/latex/psnfss/ot1ptm.fd
|
||||
File: ot1ptm.fd 2001/06/04 font definitions for OT1/ptm.
|
||||
)
|
||||
-- Using 8.5in x 11in (letter) paper.
|
||||
-- Using PDF output.
|
||||
\@IEEEnormalsizeunitybaselineskip=\dimen143
|
||||
-- This is a 10 point document.
|
||||
\CLASSINFOnormalsizebaselineskip=\dimen144
|
||||
\CLASSINFOnormalsizeunitybaselineskip=\dimen145
|
||||
\IEEEnormaljot=\dimen146
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <5> not available
|
||||
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 1090.
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/it' in size <5> not available
|
||||
(Font) Font shape `OT1/ptm/b/it' tried instead on input line 1090.
|
||||
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <7> not available
|
||||
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 1090.
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/it' in size <7> not available
|
||||
(Font) Font shape `OT1/ptm/b/it' tried instead on input line 1090.
|
||||
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <8> not available
|
||||
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 1090.
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/it' in size <8> not available
|
||||
(Font) Font shape `OT1/ptm/b/it' tried instead on input line 1090.
|
||||
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <9> not available
|
||||
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 1090.
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/it' in size <9> not available
|
||||
(Font) Font shape `OT1/ptm/b/it' tried instead on input line 1090.
|
||||
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <10> not available
|
||||
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 1090.
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/it' in size <10> not available
|
||||
(Font) Font shape `OT1/ptm/b/it' tried instead on input line 1090.
|
||||
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <11> not available
|
||||
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 1090.
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/it' in size <11> not available
|
||||
(Font) Font shape `OT1/ptm/b/it' tried instead on input line 1090.
|
||||
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <12> not available
|
||||
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 1090.
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/it' in size <12> not available
|
||||
(Font) Font shape `OT1/ptm/b/it' tried instead on input line 1090.
|
||||
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <17> not available
|
||||
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 1090.
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/it' in size <17> not available
|
||||
(Font) Font shape `OT1/ptm/b/it' tried instead on input line 1090.
|
||||
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <20> not available
|
||||
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 1090.
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/it' in size <20> not available
|
||||
(Font) Font shape `OT1/ptm/b/it' tried instead on input line 1090.
|
||||
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/n' in size <24> not available
|
||||
(Font) Font shape `OT1/ptm/b/n' tried instead on input line 1090.
|
||||
LaTeX Font Info: Font shape `OT1/ptm/bx/it' in size <24> not available
|
||||
(Font) Font shape `OT1/ptm/b/it' tried instead on input line 1090.
|
||||
|
||||
\IEEEquantizedlength=\dimen147
|
||||
\IEEEquantizedlengthdiff=\dimen148
|
||||
\IEEEquantizedtextheightdiff=\dimen149
|
||||
\IEEEilabelindentA=\dimen150
|
||||
\IEEEilabelindentB=\dimen151
|
||||
\IEEEilabelindent=\dimen152
|
||||
\IEEEelabelindent=\dimen153
|
||||
\IEEEdlabelindent=\dimen154
|
||||
\IEEElabelindent=\dimen155
|
||||
\IEEEiednormlabelsep=\dimen156
|
||||
\IEEEiedmathlabelsep=\dimen157
|
||||
\IEEEiedtopsep=\skip48
|
||||
\c@section=\count188
|
||||
\c@subsection=\count189
|
||||
\c@subsubsection=\count190
|
||||
\c@paragraph=\count191
|
||||
\c@IEEEsubequation=\count192
|
||||
\abovecaptionskip=\skip49
|
||||
\belowcaptionskip=\skip50
|
||||
\c@figure=\count193
|
||||
\c@table=\count194
|
||||
\@IEEEeqnnumcols=\count195
|
||||
\@IEEEeqncolcnt=\count196
|
||||
\@IEEEsubeqnnumrollback=\count197
|
||||
\@IEEEquantizeheightA=\dimen158
|
||||
\@IEEEquantizeheightB=\dimen159
|
||||
\@IEEEquantizeheightC=\dimen160
|
||||
\@IEEEquantizeprevdepth=\dimen161
|
||||
\@IEEEquantizemultiple=\count198
|
||||
\@IEEEquantizeboxA=\box51
|
||||
\@IEEEtmpitemindent=\dimen162
|
||||
\IEEEPARstartletwidth=\dimen163
|
||||
\c@IEEEbiography=\count199
|
||||
\@IEEEtranrubishbin=\box52
|
||||
) (/usr/share/texmf-dist/tex/latex/cite/cite.sty
|
||||
LaTeX Info: Redefining \cite on input line 302.
|
||||
LaTeX Info: Redefining \nocite on input line 332.
|
||||
Package: cite 2015/02/27 v 5.5
|
||||
)
|
||||
(/usr/share/texmf-dist/tex/latex/amsmath/amsmath.sty
|
||||
Package: amsmath 2022/04/08 v2.17n AMS math features
|
||||
\@mathmargin=\skip51
|
||||
|
||||
For additional information on amsmath, use the `?' option.
|
||||
(/usr/share/texmf-dist/tex/latex/amsmath/amstext.sty
|
||||
Package: amstext 2021/08/26 v2.01 AMS text
|
||||
|
||||
(/usr/share/texmf-dist/tex/latex/amsmath/amsgen.sty
|
||||
File: amsgen.sty 1999/11/30 v2.0 generic functions
|
||||
\@emptytoks=\toks17
|
||||
\ex@=\dimen164
|
||||
))
|
||||
(/usr/share/texmf-dist/tex/latex/amsmath/amsbsy.sty
|
||||
Package: amsbsy 1999/11/29 v1.2d Bold Symbols
|
||||
\pmbraise@=\dimen165
|
||||
)
|
||||
(/usr/share/texmf-dist/tex/latex/amsmath/amsopn.sty
|
||||
Package: amsopn 2022/04/08 v2.04 operator names
|
||||
)
|
||||
\inf@bad=\count266
|
||||
LaTeX Info: Redefining \frac on input line 234.
|
||||
\uproot@=\count267
|
||||
\leftroot@=\count268
|
||||
LaTeX Info: Redefining \overline on input line 399.
|
||||
LaTeX Info: Redefining \colon on input line 410.
|
||||
\classnum@=\count269
|
||||
\DOTSCASE@=\count270
|
||||
LaTeX Info: Redefining \ldots on input line 496.
|
||||
LaTeX Info: Redefining \dots on input line 499.
|
||||
LaTeX Info: Redefining \cdots on input line 620.
|
||||
\Mathstrutbox@=\box53
|
||||
\strutbox@=\box54
|
||||
LaTeX Info: Redefining \big on input line 722.
|
||||
LaTeX Info: Redefining \Big on input line 723.
|
||||
LaTeX Info: Redefining \bigg on input line 724.
|
||||
LaTeX Info: Redefining \Bigg on input line 725.
|
||||
\big@size=\dimen166
|
||||
LaTeX Font Info: Redeclaring font encoding OML on input line 743.
|
||||
LaTeX Font Info: Redeclaring font encoding OMS on input line 744.
|
||||
\macc@depth=\count271
|
||||
LaTeX Info: Redefining \bmod on input line 905.
|
||||
LaTeX Info: Redefining \pmod on input line 910.
|
||||
LaTeX Info: Redefining \smash on input line 940.
|
||||
LaTeX Info: Redefining \relbar on input line 970.
|
||||
LaTeX Info: Redefining \Relbar on input line 971.
|
||||
\c@MaxMatrixCols=\count272
|
||||
\dotsspace@=\muskip16
|
||||
\c@parentequation=\count273
|
||||
\dspbrk@lvl=\count274
|
||||
\tag@help=\toks18
|
||||
\row@=\count275
|
||||
\column@=\count276
|
||||
\maxfields@=\count277
|
||||
\andhelp@=\toks19
|
||||
\eqnshift@=\dimen167
|
||||
\alignsep@=\dimen168
|
||||
\tagshift@=\dimen169
|
||||
\tagwidth@=\dimen170
|
||||
\totwidth@=\dimen171
|
||||
\lineht@=\dimen172
|
||||
\@envbody=\toks20
|
||||
\multlinegap=\skip52
|
||||
\multlinetaggap=\skip53
|
||||
\mathdisplay@stack=\toks21
|
||||
LaTeX Info: Redefining \[ on input line 2953.
|
||||
LaTeX Info: Redefining \] on input line 2954.
|
||||
)
|
||||
(/usr/share/texmf-dist/tex/latex/amsfonts/amssymb.sty
|
||||
Package: amssymb 2013/01/14 v3.01 AMS font symbols
|
||||
|
||||
(/usr/share/texmf-dist/tex/latex/amsfonts/amsfonts.sty
|
||||
Package: amsfonts 2013/01/14 v3.01 Basic AMSFonts support
|
||||
\symAMSa=\mathgroup4
|
||||
\symAMSb=\mathgroup5
|
||||
LaTeX Font Info: Redeclaring math symbol \hbar on input line 98.
|
||||
LaTeX Font Info: Overwriting math alphabet `\mathfrak' in version `bold'
|
||||
(Font) U/euf/m/n --> U/euf/b/n on input line 106.
|
||||
))
|
||||
(/usr/share/texmf-dist/tex/latex/algorithms/algorithmic.sty
|
||||
Package: algorithmic 2009/08/24 v0.1 Document Style `algorithmic'
|
||||
|
||||
(/usr/share/texmf-dist/tex/latex/base/ifthen.sty
|
||||
Package: ifthen 2022/04/13 v1.1d Standard LaTeX ifthen package (DPC)
|
||||
)
|
||||
(/usr/share/texmf-dist/tex/latex/graphics/keyval.sty
|
||||
Package: keyval 2022/05/29 v1.15 key=value parser (DPC)
|
||||
\KV@toks@=\toks22
|
||||
)
|
||||
\c@ALC@unique=\count278
|
||||
\c@ALC@line=\count279
|
||||
\c@ALC@rem=\count280
|
||||
\c@ALC@depth=\count281
|
||||
\ALC@tlm=\skip54
|
||||
\algorithmicindent=\skip55
|
||||
)
|
||||
(/usr/share/texmf-dist/tex/latex/graphics/graphicx.sty
|
||||
Package: graphicx 2021/09/16 v1.2d Enhanced LaTeX Graphics (DPC,SPQR)
|
||||
|
||||
(/usr/share/texmf-dist/tex/latex/graphics/graphics.sty
|
||||
Package: graphics 2022/03/10 v1.4e Standard LaTeX Graphics (DPC,SPQR)
|
||||
|
||||
(/usr/share/texmf-dist/tex/latex/graphics/trig.sty
|
||||
Package: trig 2021/08/11 v1.11 sin cos tan (DPC)
|
||||
)
|
||||
(/usr/share/texmf-dist/tex/latex/graphics-cfg/graphics.cfg
|
||||
File: graphics.cfg 2016/06/04 v1.11 sample graphics configuration
|
||||
)
|
||||
Package graphics Info: Driver file: pdftex.def on input line 107.
|
||||
|
||||
(/usr/share/texmf-dist/tex/latex/graphics-def/pdftex.def
|
||||
File: pdftex.def 2022/09/22 v1.2b Graphics/color driver for pdftex
|
||||
))
|
||||
\Gin@req@height=\dimen173
|
||||
\Gin@req@width=\dimen174
|
||||
)
|
||||
(/usr/share/texmf-dist/tex/generic/babel/babel.sty
|
||||
Package: babel 2023/02/13 3.86 The Babel package
|
||||
\babel@savecnt=\count282
|
||||
\U@D=\dimen175
|
||||
\l@unhyphenated=\language3
|
||||
|
||||
(/usr/share/texmf-dist/tex/generic/babel/txtbabel.def)
|
||||
\bbl@readstream=\read2
|
||||
\bbl@dirlevel=\count283
|
||||
Package babel Info: You haven't specified a language as a class or package
|
||||
(babel) option. I'll load 'nil'. Reported on input line 4422.
|
||||
|
||||
(/usr/share/texmf-dist/tex/generic/babel/nil.ldf
|
||||
Language: nil 2023/02/13 3.86 Nil language
|
||||
\l@nil=\language4
|
||||
))
|
||||
(/usr/share/texmf-dist/tex/latex/base/textcomp.sty
|
||||
Package: textcomp 2020/02/02 v2.0n Standard LaTeX package
|
||||
)
|
||||
(/usr/share/texmf-dist/tex/latex/base/inputenc.sty
|
||||
Package: inputenc 2021/02/14 v1.3d Input encoding file
|
||||
\inpenc@prehook=\toks23
|
||||
\inpenc@posthook=\toks24
|
||||
)
|
||||
(/usr/share/texmf-dist/tex/latex/float/float.sty
|
||||
Package: float 2001/11/08 v1.3d Float enhancements (AL)
|
||||
\c@float@type=\count284
|
||||
\float@exts=\toks25
|
||||
\float@box=\box55
|
||||
\@float@everytoks=\toks26
|
||||
\@floatcapt=\box56
|
||||
)
|
||||
(/usr/share/texmf-dist/tex/latex/xcolor/xcolor.sty
|
||||
Package: xcolor 2022/06/12 v2.14 LaTeX color extensions (UK)
|
||||
|
||||
(/usr/share/texmf-dist/tex/latex/graphics-cfg/color.cfg
|
||||
File: color.cfg 2016/01/02 v1.6 sample color configuration
|
||||
)
|
||||
Package xcolor Info: Driver file: pdftex.def on input line 227.
|
||||
|
||||
(/usr/share/texmf-dist/tex/latex/graphics/mathcolor.ltx)
|
||||
Package xcolor Info: Model `cmy' substituted by `cmy0' on input line 1353.
|
||||
Package xcolor Info: Model `hsb' substituted by `rgb' on input line 1357.
|
||||
Package xcolor Info: Model `RGB' extended on input line 1369.
|
||||
Package xcolor Info: Model `HTML' substituted by `rgb' on input line 1371.
|
||||
Package xcolor Info: Model `Hsb' substituted by `hsb' on input line 1372.
|
||||
Package xcolor Info: Model `tHsb' substituted by `hsb' on input line 1373.
|
||||
Package xcolor Info: Model `HSB' substituted by `hsb' on input line 1374.
|
||||
Package xcolor Info: Model `Gray' substituted by `gray' on input line 1375.
|
||||
Package xcolor Info: Model `wave' substituted by `hsb' on input line 1376.
|
||||
)
|
||||
(/usr/share/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
|
||||
File: l3backend-pdftex.def 2023-01-16 L3 backend support: PDF output (pdfTeX)
|
||||
\l__color_backend_stack_int=\count285
|
||||
\l__pdf_internal_box=\box57
|
||||
)
|
||||
(./Schrick-Noah_AG-CG-CR.aux)
|
||||
\openout1 = `Schrick-Noah_AG-CG-CR.aux'.
|
||||
|
||||
LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 15.
|
||||
LaTeX Font Info: ... okay on input line 15.
|
||||
LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 15.
|
||||
LaTeX Font Info: ... okay on input line 15.
|
||||
LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 15.
|
||||
LaTeX Font Info: ... okay on input line 15.
|
||||
LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 15.
|
||||
LaTeX Font Info: ... okay on input line 15.
|
||||
LaTeX Font Info: Checking defaults for TS1/cmr/m/n on input line 15.
|
||||
LaTeX Font Info: ... okay on input line 15.
|
||||
LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 15.
|
||||
LaTeX Font Info: ... okay on input line 15.
|
||||
LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 15.
|
||||
LaTeX Font Info: ... okay on input line 15.
|
||||
|
||||
-- Lines per column: 56 (exact).
|
||||
(/usr/share/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
|
||||
[Loading MPS to PDF converter (version 2006.09.02).]
|
||||
\scratchcounter=\count286
|
||||
\scratchdimen=\dimen176
|
||||
\scratchbox=\box58
|
||||
\nofMPsegments=\count287
|
||||
\nofMParguments=\count288
|
||||
\everyMPshowfont=\toks27
|
||||
\MPscratchCnt=\count289
|
||||
\MPscratchDim=\dimen177
|
||||
\MPnumerator=\count290
|
||||
\makeMPintoPDFobject=\count291
|
||||
\everyMPtoPDFconversion=\toks28
|
||||
) (/usr/share/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
|
||||
Package: epstopdf-base 2020-01-24 v2.11 Base part for package epstopdf
|
||||
Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4
|
||||
85.
|
||||
|
||||
(/usr/share/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg
|
||||
File: epstopdf-sys.cfg 2010/07/13 v1.3 Configuration of (r)epstopdf for TeX Liv
|
||||
e
|
||||
))
|
||||
LaTeX Font Info: Calculating math sizes for size <11> on input line 35.
|
||||
LaTeX Font Info: Trying to load font information for U+msa on input line 35.
|
||||
|
||||
|
||||
(/usr/share/texmf-dist/tex/latex/amsfonts/umsa.fd
|
||||
File: umsa.fd 2013/01/14 v3.01 AMS symbols A
|
||||
)
|
||||
LaTeX Font Info: Trying to load font information for U+msb on input line 35.
|
||||
|
||||
|
||||
(/usr/share/texmf-dist/tex/latex/amsfonts/umsb.fd
|
||||
File: umsb.fd 2013/01/14 v3.01 AMS symbols B
|
||||
)
|
||||
** WARNING: \IEEEPARstart is locked out when in conference mode (line 46).
|
||||
|
||||
Underfull \hbox (badness 2158) in paragraph at lines 48--55
|
||||
[]\OT1/ptm/m/n/10 Despite their advantages, graph generation has many
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 3557) in paragraph at lines 61--62
|
||||
\OT1/ptm/m/n/10 reliability. User-level checkpointing, though has greater
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 3417) in paragraph at lines 61--62
|
||||
\OT1/ptm/m/n/10 Checkpoint/Restart) library, which has seen widespread
|
||||
[]
|
||||
|
||||
|
||||
Underfull \vbox (badness 10000) has occurred while \output is active []
|
||||
|
||||
[1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}{/usr/share/texmf-dist/fo
|
||||
nts/enc/dvips/base/8r.enc}
|
||||
|
||||
|
||||
]
|
||||
<./images/schri1.png, id=10, 755.82375pt x 402.50375pt>
|
||||
File: ./images/schri1.png Graphic file (type png)
|
||||
<use ./images/schri1.png>
|
||||
Package pdftex.def Info: ./images/schri1.png used on input line 72.
|
||||
(pdftex.def) Requested size: 252.0pt x 134.19624pt.
|
||||
|
||||
Underfull \hbox (badness 3158) in paragraph at lines 78--83
|
||||
\OT1/ptm/m/it/10 1) Memory Constraint Difficulties: [][] \OT1/ptm/m/n/10 While
|
||||
the design
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 91--97
|
||||
\OT1/ptm/m/it/10 2) Implementation: [][] \OT1/ptm/m/n/10 Rather than only a st
|
||||
atic
|
||||
[]
|
||||
|
||||
[2 <./images/schri1.png>]
|
||||
Underfull \hbox (badness 4660) in paragraph at lines 113--118
|
||||
\OT1/ptm/m/it/10 3) Portability: [][] \OT1/ptm/m/n/10 The checkpointing proces
|
||||
s is greatly
|
||||
[]
|
||||
|
||||
[3]
|
||||
<./images/schri2.png, id=20, 720.6925pt x 297.11pt>
|
||||
File: ./images/schri2.png Graphic file (type png)
|
||||
<use ./images/schri2.png>
|
||||
Package pdftex.def Info: ./images/schri2.png used on input line 129.
|
||||
(pdftex.def) Requested size: 252.0pt x 103.88577pt.
|
||||
<./images/schri3.png, id=21, 695.59875pt x 341.275pt>
|
||||
File: ./images/schri3.png Graphic file (type png)
|
||||
<use ./images/schri3.png>
|
||||
Package pdftex.def Info: ./images/schri3.png used on input line 138.
|
||||
(pdftex.def) Requested size: 252.0pt x 123.6348pt.
|
||||
<./images/schri4.png, id=22, 612.2875pt x 331.2375pt>
|
||||
File: ./images/schri4.png Graphic file (type png)
|
||||
<use ./images/schri4.png>
|
||||
Package pdftex.def Info: ./images/schri4.png used on input line 147.
|
||||
(pdftex.def) Requested size: 252.0pt x 136.32883pt.
|
||||
|
||||
Underfull \hbox (badness 1622) in paragraph at lines 153--154
|
||||
\OT1/ptm/m/n/10 function calls or snapshots that are required. The C/R
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 2150) in paragraph at lines 155--156
|
||||
\OT1/ptm/m/n/10 checkpoint times and sizes, as well as time taken to
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 1565) in paragraph at lines 155--156
|
||||
\OT1/ptm/m/n/10 settings to alter or enable, or communication strategies
|
||||
[]
|
||||
|
||||
(./Schrick-Noah_AG-CG-CR.bbl [4 <./images/schri2.png> <./images/schri3.png> <./
|
||||
images/schri4.png>]
|
||||
Underfull \hbox (badness 2351) in paragraph at lines 27--30
|
||||
[]\OT1/ptm/m/n/8 S. Ainsworth and T. M. Jones, ``Graph prefetching using data
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 1616) in paragraph at lines 48--52
|
||||
\OT1/ptm/m/n/8 modeling, and evaluation of a scalable multi-level checkpointing
|
||||
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 5091) in paragraph at lines 54--56
|
||||
[]\OT1/ptm/m/n/8 J. Ansel, K. Arya, and G. Cooperman, ``Dmtcp: Transparent
|
||||
[]
|
||||
|
||||
)
|
||||
|
||||
** Conference Paper **
|
||||
Before submitting the final camera ready copy, remember to:
|
||||
|
||||
1. Manually equalize the lengths of two columns on the last page
|
||||
of your paper;
|
||||
|
||||
2. Ensure that any PostScript and/or PDF output post-processing
|
||||
uses only Type 1 fonts and that every step in the generation
|
||||
process uses the appropriate paper size.
|
||||
|
||||
[5
|
||||
|
||||
] (./Schrick-Noah_AG-CG-CR.aux) )
|
||||
Here is how much of TeX's memory you used:
|
||||
5332 strings out of 477985
|
||||
84855 string characters out of 5840059
|
||||
1864388 words of memory out of 5000000
|
||||
25473 multiletter control sequences out of 15000+600000
|
||||
549821 words of font info for 106 fonts, out of 8000000 for 9000
|
||||
14 hyphenation exceptions out of 8191
|
||||
57i,11n,62p,1435b,333s stack positions out of 10000i,1000n,20000p,200000b,200000s
|
||||
</usr/share/texmf-dist/fonts/type1/public/amsf
|
||||
onts/cm/cmmi10.pfb></usr/share/texmf-dist/fonts/type1/urw/times/utmb8a.pfb></us
|
||||
r/share/texmf-dist/fonts/type1/urw/times/utmbi8a.pfb></usr/share/texmf-dist/fon
|
||||
ts/type1/urw/times/utmr8a.pfb></usr/share/texmf-dist/fonts/type1/urw/times/utmr
|
||||
i8a.pfb>
|
||||
Output written on Schrick-Noah_AG-CG-CR.pdf (5 pages, 190866 bytes).
|
||||
PDF statistics:
|
||||
55 PDF objects out of 1000 (max. 8388607)
|
||||
29 compressed objects within 1 object stream
|
||||
0 named destinations out of 1000 (max. 500000)
|
||||
21 words of extra memory for PDF output out of 10000 (max. 10000000)
|
||||
|
||||
11
SoutheastCon/Original Submission/Schrick-Noah_AG-CG-CR.out
Normal file
11
SoutheastCon/Original Submission/Schrick-Noah_AG-CG-CR.out
Normal file
@ -0,0 +1,11 @@
|
||||
\BOOKMARK [1][-]{section.1}{\376\377\000I\000n\000t\000r\000o\000d\000u\000c\000t\000i\000o\000n}{}% 1
|
||||
\BOOKMARK [1][-]{section.2}{\376\377\000R\000e\000l\000a\000t\000e\000d\000\040\000W\000o\000r\000k}{}% 2
|
||||
\BOOKMARK [1][-]{section.3}{\376\377\000M\000e\000t\000h\000o\000d\000o\000l\000o\000g\000y}{}% 3
|
||||
\BOOKMARK [2][-]{subsection.3.1}{\376\377\000C\000h\000e\000c\000k\000p\000o\000i\000n\000t\000i\000n\000g}{section.3}% 4
|
||||
\BOOKMARK [3][-]{subsubsection.3.1.1}{\376\377\000M\000e\000m\000o\000r\000y\000\040\000C\000o\000n\000s\000t\000r\000a\000i\000n\000t\000\040\000D\000i\000f\000f\000i\000c\000u\000l\000t\000i\000e\000s}{subsection.3.1}% 5
|
||||
\BOOKMARK [3][-]{subsubsection.3.1.2}{\376\377\000I\000m\000p\000l\000e\000m\000e\000n\000t\000a\000t\000i\000o\000n}{subsection.3.1}% 6
|
||||
\BOOKMARK [3][-]{subsubsection.3.1.3}{\376\377\000P\000o\000r\000t\000a\000b\000i\000l\000i\000t\000y}{subsection.3.1}% 7
|
||||
\BOOKMARK [2][-]{subsection.3.2}{\376\377\000R\000e\000s\000t\000a\000r\000t\000i\000n\000g}{section.3}% 8
|
||||
\BOOKMARK [1][-]{section.4}{\376\377\000R\000e\000s\000u\000l\000t\000s}{}% 9
|
||||
\BOOKMARK [1][-]{section.5}{\376\377\000C\000o\000n\000c\000l\000u\000s\000i\000o\000n\000s\000\040\000a\000n\000d\000\040\000F\000u\000t\000u\000r\000e\000\040\000W\000o\000r\000k}{}% 10
|
||||
\BOOKMARK [1][-]{section*.1}{\376\377\000R\000e\000f\000e\000r\000e\000n\000c\000e\000s}{}% 11
|
||||
BIN
SoutheastCon/Original Submission/Schrick-Noah_AG-CG-CR.pdf
Normal file
BIN
SoutheastCon/Original Submission/Schrick-Noah_AG-CG-CR.pdf
Normal file
Binary file not shown.
161
SoutheastCon/Original Submission/Schrick-Noah_AG-CG-CR.tex
Normal file
161
SoutheastCon/Original Submission/Schrick-Noah_AG-CG-CR.tex
Normal file
@ -0,0 +1,161 @@
|
||||
\documentclass[conference]{IEEEtran}
|
||||
\usepackage{cite}
|
||||
\usepackage{amsmath,amssymb,amsfonts}
|
||||
\usepackage{algorithmic}
|
||||
\usepackage{graphicx}
|
||||
\graphicspath{ {./images/} }
|
||||
\usepackage{babel} % Bibliography
|
||||
\usepackage{textcomp}
|
||||
\usepackage[utf8]{inputenc}
|
||||
\usepackage{float}
|
||||
\usepackage{xcolor}
|
||||
\def\BibTeX{{\rm B\kern-.05em{\sc i\kern-.025em b}\kern-.08em
|
||||
T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\title{Application-Level Checkpoint/Restart for Large-Scale Attack and Compliance Graphs
|
||||
}
|
||||
|
||||
\author{\IEEEauthorblockN{1\textsuperscript{st} Noah L. Schrick}
|
||||
\IEEEauthorblockA{\textit{Tandy School of Computer Science} \\
|
||||
\textit{University of Tulsa}\\
|
||||
Tulsa, USA \\
|
||||
noah-schrick@utulsa.edu \\
|
||||
ORCID: 0000-0003-0875-8927}
|
||||
\and
|
||||
\IEEEauthorblockN{2\textsuperscript{nd} Peter J. Hawrylak}
|
||||
\IEEEauthorblockA{\textit{Tandy School of Computer Science} \\
|
||||
\textit{University of Tulsa}\\
|
||||
Tulsa, USA \\
|
||||
peter-hawrylak@utulsa.edu \\
|
||||
ORCID: 0000-0003-3268-7452}
|
||||
}
|
||||
|
||||
\maketitle
|
||||
|
||||
\begin{abstract}
|
||||
Attack graphs and compliance graphs are graphical representations of systems used to analyze their standings in regards to cybersecurity or compliance postures. These graphs are designed to examine all permutations and combinations of changes that can occur to systems, and represent those changes through the topological information of the resulting graph. Due to their exhaustive nature, these graphs are often large-scale. Various efforts have shown success in the parallelization and generation deployment on High-Performance Computing (HPC) systems. Despite the additional compute power that HPC systems provide, these large-scale graphs still posses lengthy runtimes and require large amounts of system memory to fully contain the resulting graph. This work presents a Checkpoint/Restart (C/R) implementation specific to attack and compliance graphs that aims to provide fault-tolerance and memory relief throughout the generation process. This implementation has been designed to be built within the graph generation source code, and provides a lightweight alternative to other C/R implementations. The results indicate that this implementation is successful at providing fault-tolerance and memory relief while having low impact to the generation process and to the source code.
|
||||
\end{abstract}
|
||||
|
||||
\begin{IEEEkeywords}
|
||||
Attack Graph; Compliance Graph; MPI; High-Performance Computing; Checkpoint/Restart;
|
||||
\end{IEEEkeywords}
|
||||
|
||||
\section{Introduction} \label{sec:Intro}
|
||||
\IEEEPARstart{I}{n} order to predict and prevent the risk of cyber attacks, various modeling and tabletop approaches are implemented to best prepare for attack scenarios. One approach is through the use of attack graphs, originally presented by the author of \cite{schneier_modeling_1999}. Attack graphs represent possible attack scenarios or vulnerability paths in a network. These graphs consist of nodes and edges, with various information encoded at the topological level as well as within the nodes themselves. Similarly, compliance graphs are used to predict and prevent violations of compliance or regulation mandates \cite{j_hale_compliance_nodate}. These graphs are now generated through the use of attack or compliance graph generators, rather than by hand. The generator tool used for the implementation of this work is RAGE (the RAGE Attack Graph Engine) \cite{cook_rage_2018}.
|
||||
|
||||
Despite their advantages, graph generation has many challenges that prevent full actualization of computation seen from a theoretical standpoint, and these challenges extend to attack and compliance graphs.
|
||||
In practice, graph generation often achieves only a very low percentage of its expected performance \cite{berry_graph_2007}. A few reasons
|
||||
for this occurrence lie in the underlying mechanisms of graph generation. The generation is predominantly memory based (as opposed to based on processor speed),
|
||||
where performance is tied to memory access time, the complexity of data dependency, and coarseness of parallelism \cite{berry_graph_2007}, \cite{zhang_boosting_2017},
|
||||
\cite{ainsworth_graph_2016}. Graphs consume large amounts of memory through their
|
||||
nodes and edges, graph data structures suffer from poor cache locality, and memory latency from the processor-memory gap all slow the generation process dramatically
|
||||
\cite{berry_graph_2007}, \cite{ainsworth_graph_2016}.
|
||||
|
||||
The author of \cite{cook_rage_2018} discusses the challenges of attack graph generation in regards to its scalability. Specifically, the author of \cite{cook_rage_2018} displays results from generations based on small networks that result in a large state space. The authors of \cite{ou_scalable_2006} also present the scalability challenges of attack graphs. Their findings indicate that small networks result in graphs with total edges and nodes in the order of millions. Generating an attack or compliance graph based on a large network with a multitude of assets and involving a more thorough exploit or compliance violation checking will prevent the entire graph from being stored in memory as originally designed.
|
||||
|
||||
Due to the runtime requirements and scalability challenges imposed by graph generation, fault-tolerance is critical to ensure reliable generation. These difficulties highlight the need for fault-tolerance and non-volatile memory (memory) relief approaches. The ability to safely checkpoint and recover from a system error is crucial to avoid duplicated work or needing to request more cycles on an HPC cluster. In addition, having the ability to minimize the memory strain without requesting excess RAM on an HPC cluster assists in reducing incurred cost. This work presents an application-level checkpoint/restart (C/R) approach tailored to large-scale graph generation. This work illustrates the advantages in having a C/R system built into the generation process itself, rather than using alternative libraries. By having native C/R, performance can be maximized and runtime interruption and overhead can be minimized. This C/R approach allows the user to ensure fault-tolerance for graph generation without the reliance on a system-level, HPC cluster implementation of C/R.
|
||||
|
||||
\section{Related Work} \label{sec:Rel-Works}
|
||||
Numerous efforts have been presented for C/R techniques with various categories available. The authors of \cite{CR-Survey} and \cite{hursey2010coordinated} discuss three categories of C/R, which include application-level, user-level, and system-level. Each approach draws upon advantages that appeal toward different aspects of reliability. User-level checkpointing, though has greater simplicity, results in larger checkpoints. System-level requires compatibility with the operating system and any libraries used for the application. Application-level checkpointing requires additional work for the implementation, but resuls in smaller, faster C/R. The authors of \cite{SCR} present the SCR (Scalable Checkpoint/Restart) library, which has seen widespread adoption due to its minimal overhead. DMTCP (Distributed MultiThreaded Checkpointing) \cite{dmtcp} and BLCR (Berkely Lab Checkpoint/Restart) \cite{BLCR} are two other commonly-used C/R approaches.
|
||||
|
||||
Other investigations into attack and compliance graphs attempt to improve performance and scalability to mitigate state space explosion or lengthy runtimes, rather than focus on C/R. These investigations include the works by the authors of \cite{GraphDB}, which implement attack graph methodologies using Neo4j for efficient storage techniques. This approach has seen other implementations, such as that shown by the authors of \cite{Graph-DB}. Other attack graph scalability studies involve the alteration of the representation schemes. The authors of \cite{ou_scalable_2006} make use of logical statements for logical attack graphs. This approach has seen continued investigations, and similar logic-based attack graphs can be seen in the work presented by the authors of \cite{LAPA}. These logical based attack graphs aim to improve scalability by minimizing the resulting information. Other representation schemes include those seen by the authors of \cite{cook_scalable_2016} and the authors of \cite{li_concurrency_2019}, which make use of qualities and topologies through graph states. Scalability improvements have also been examined through sampling, such as the approach presented by the authors of \cite{AG-Sample}. Parallelization techniques have been investigated for runtime improvement, and successful results have been seen in the work by the authors of \cite{7087377}.
|
||||
|
||||
\section{Methodology}
|
||||
\subsection{Checkpointing}
|
||||
Previous works with RAGE have been designed around maximizing performance to limit the longer runtime caused by the state space explosion, such as the works seen by the authors of \cite{cook_rage_2018},
|
||||
\cite{li_concurrency_2019}, and \cite{li_combining_2019}. To this end, the output graph is contained in memory during the generation process to minimize disk writing and reading. RAGE does incorporate PostgreSQL as an initial and final storage mechanism to write the starting and resulting graph information, but no intermediate storage is otherwise conducted. Based on the inclusion of PostgreSQL in RAGE, the C/R approach was based around this dependency. Fig. \ref{fig:cr} shows an image of an attack or compliance graph that is undergoing the generation process. All nodes and edges within the ``instance" box have been fully explored, and all information is stored in memory. All nodes within the ``frontier" box have their information stored in memory, but they have not yet undergone exploration. To checkpoint at this point in time, both the instance and the frontier need to be saved. Additionally, since the instance will no longer be used, it can be fully removed from memory. Section \ref{sec:mem-constraint} highlights the advantages and necessities of this removal.
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{"./images/schri1.png"}
|
||||
\caption{An Attack or Compliance Graph Undergoing Generation}
|
||||
\label{fig:cr}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{Memory Constraint Difficulties} \label{sec:mem-constraint}
|
||||
While the design decision to store all graph generation information in memory maximizes performance, it introduces a few complications. When generating large graphs, the system runs the risk
|
||||
of running out of memory. This typically does not occur when generation is conducted on small graphs, and is especially true when relatively small graphs are generated on an HPC
|
||||
system with substantial amounts of memory. However, when running on local systems or when the graph is large, memory can quickly be depleted due to state space explosion. The memory depletion is due to two primary
|
||||
memory consumption points: the frontier which contains all of the states that still need to be explored, and the graph instance which holds all of the states and their information,
|
||||
as well as all of the edges.
|
||||
|
||||
The frontier rapidly strains memory with large graphs that have a large height value and contain many layers before the leaf nodes. During the generation process, RAGE works on a Breadth-First Search approach, and new states
|
||||
are continuously discovered each time a state from the frontier is explored. In almost all cases, this means that for every state that is removed from the frontier, several more are added, leading to a rapidly increasing
|
||||
frontier that can not be adequately reduced for large networks. Simultaneously, the graph instance continues to grow as states are explored. When the network contains numerous assets, each with their own large sets of
|
||||
qualities, the size of each state becomes noticeably larger. With some graphs containing millions of nodes and billions of edges like those mentioned by the authors of \cite{zhang_boosting_2017}, it becomes increasingly
|
||||
unlikely that the graph can be fully contained within system memory. Checkpointing provides an additional benefit to the generation process to relieve its memory strain.
|
||||
|
||||
\subsubsection{Implementation}
|
||||
Rather than only a static implementation of storing to the database on disk at a set interval or a set size, the goal was to also allow for dynamically storing to the database only when necessary. This would allow for proper utilization of systems with greater memory, and would reduce fine-tuning of a maximum size variable before database writes on different systems. Since there is an associated cost with preparing
|
||||
the writes to disk, the communication cost across nodes, the writing to disk itself, and a cost for retrieving items from disk, it may be desirable to store as much in memory for as long as possible and only checkpoint when necessary. When
|
||||
running RAGE, a new argument can be passed \textit{(-a $<$double$>$)} to specify the amount of memory the tool should use before writing to disk. This argument is a value between 0 and 0.99 to specify a percentage. Alternatively, an integer greater than or equal to 1 can be passed, which allows for a discrete number of states to be held in memory before checkpointing.
|
||||
If the value passed is between 0 and 1, it is immediately reduced by a static subtraction of 10\%. For instance, if 0.6 (60\%) is passed, it is immediately reduced by a static subtraction of 10\% to yield 0.5 (0.6-0.1=0.5, or 60\%-10\%=50\%). This acts as a buffer for PostgreSQL. Since queries will consume a variable amount of memory through parsing or preparation,
|
||||
an additional 10\% is saved as a precaution. This can be changed as needed or desired for future optimizations. Specific to the graph data, the statement is made that the frontier is allowed to consume half of the allocated memory,
|
||||
and that the graph instance is allowed to consume the other half.
|
||||
|
||||
To decide when to checkpoint due to memory capacity, two separate checks are made. The first check is for the frontier. If the size of the frontier consumes equal to or more than the allowed allocated memory, then all new states
|
||||
are stored into a new table in the database called “unexplored states”. Each new state from this point forward is stored in the table, regardless of if room is freed in the frontier. This is to ensure proper ordering of the FIFO queue.
|
||||
The only time new states are stored directly into the frontier is when the unexplored states table is empty. Once the frontier has been completely emptied, new states are then pulled from the database into the frontier. To pull from
|
||||
the database, the parent loop for the generator process has been altered. Instead of a while loop for when the frontier is not empty, it has been adjusted to when the frontier is not empty or, if the frontier is empty, if the unexplored states table is not empty. The original generation design stored new states
|
||||
into the frontier during an OpenMP critical section to avoid testing on already-explored states. To follow this design decision, writing new states to the database is also performed during the critical section.
|
||||
|
||||
For the graph instance, a check in the critical section determines if the size of the graph instance consumes more than its allocated share of the memory. If it does, the edges, network states, and network state items are written to the database,
|
||||
and are then removed from memory.
|
||||
|
||||
The original design was to save staging, preparation, and communication cost by writing all the data in one query (writing all of the network states in one query, all the network
|
||||
state items in one query, and all the edges in one query). While this was best option in terms of performance, it was also not feasible when the amount of data to store was large in relation to system memory. Building the SQL queries themselves quickly began depleting the already constrained memory with large storage
|
||||
requests. As a result, the storage process would consume too much memory and invoke the Out-of-Memory Killer. To combat this, all queries had to be broken up into multiple queries. As previously mentioned, an extra 10\% buffer was saved
|
||||
for the storage process. SQL query strings are now built until they consume the 10\% buffer, where they are then processed by PostgreSQL, cleared, and the query building process resumes.
|
||||
|
||||
\subsubsection{Portability}
|
||||
The checkpointing process is greatly advantageous in increasing the portability of RAGE across various systems, while still allowing for performance benefits. By allowing for a user-defined argument, users can safely assign
|
||||
a value that allows for other processes and for the host OS to continue their workloads. While the ``total memory" component currently utilizes the Linux \textit{sysconf()} function, additional functionality can be built for alternative operating systems.
|
||||
When working on an HPC cluster, using this function could lead to difficulties since multiple users may be working on the same nodes, which prevents RAGE from fully using all system memory. This could be prevented
|
||||
by using a job scheduler argument such as Slurm's ``--exclusive" option, but this may not be desirable. Instead, a user could pass in the amount of total memory to use (and can be reused from a job scheduler's memory allocation
|
||||
request option), and the checkpointing process would function in the same fashion. Since PostgreSQL is used for the checkpointing, no file system dependencies are necessary for the cluster.
|
||||
|
||||
\subsection{Restarting}
|
||||
The restarting process for attack and compliance graph generation requires only a limited set of information. In order for a proper generation restart, the generator first needs to pull the unexplored queue (``frontier") database table into memory. After the frontier is loaded, the generator tool needs to know at which integer to begin tagging new states. This is accomplished by checking the ID of the latest state in the frontier. Since the instance has already been explored, it does not need to be retrieved from disk. In addition, the frontier is a queue of unexplored nodes. Since these nodes have yet to be explored, no edge information is available, and as a result, no edge information is required. At this point, the generator tool is able to pop the first node from the queue and resume the generation process.
|
||||
|
||||
\section{Results}
|
||||
Results were collected to measure the checkpointing time as a function of the instance size in bytes, as well as the frontier size in bytes. The restart results were collected to measure the time taken to restart as a function of the frontier size in bytes. In order to mitigate the non-deterministic effects of networking as much as possible, the checkpointing and restarting processes were called by a compute node that was also running the PostgreSQL instance.
|
||||
|
||||
Fig. \ref{fig:inst-time} displays the time taken to checkpoint as the instance size grows. The size of the instance was measured in bytes to allow for abstracting the number of items in the instance and the size of each item. This figure demonstrates that as the instance grows, the time taken to checkpoint remains linear. This figure includes two trendlines - one for a linear fit, and one for a logarithmic fit. Though the logarithmic fit appears to match the data better than the linear fit when the instance size is less than 20MB, the accuracy begins to decrease after this size. Based on the timing data obtained, the logarithmic fit predicts higher than the actual data for smaller instances, and the linear fit predicts lower than the actual data.
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{"./images/schri2.png"}
|
||||
\caption{Time Taken to Checkpoint as the Size of the Instance Grows}
|
||||
\label{fig:inst-time}
|
||||
\end{figure}
|
||||
|
||||
Fig. \ref{fig:front-chk-time} displays the time taken to checkpoint as the frontier size grows. Similar to the instance size, the frontier was also measured in bytes for consistency. This figure illustrates that as the frontier grows, the checkpoint time also remains linear. Compared to the time taken to checkpoint the instance, the frontier requires less time. Since the graph instance contains various topological information such as edges and edge labels, additional time is required compared to the frontier.
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{"./images/schri3.png"}
|
||||
\caption{Time Taken to Checkpoint as the Size of the Frontier Grows}
|
||||
\label{fig:front-chk-time}
|
||||
\end{figure}
|
||||
|
||||
Fig. \ref{fig:front-rest-time} displays the time taken to restart as the frontier size grows. The frontier was again measured in bytes. This figure illustrates that the restart time remains linear as the size of the frontier grows. This figure shows that there is less time taken to restart due to the limited amount of information needed to restart compared to the information needed to checkpoint. Since the checkpointing process involves saving the graph instance and the frontier, extra time is required compared to the restart process which only requires the queue of unexplored states.
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{"./images/schri4.png"}
|
||||
\caption{Time Taken to Restart as the Size of the Frontier Grows}
|
||||
\label{fig:front-rest-time}
|
||||
\end{figure}
|
||||
|
||||
\section{Conclusions and Future Work}
|
||||
This work presents an application-level approach at C/R. This approach was built into RAGE itself, and has no dependencies on C/R libraries. In addition, it does not need support from the operating system, allowing for fault-tolerance on HPC clusters that may not support C/R. The results highlight the minimal time requirement to both checkpoint and restart the generation process. Since only the necessary information is stored and retrieved, there are no lengthy function calls or snapshots that are required. The C/R implemented also serves as a form of memory relief. Due to the size of large-scale attack and compliance graphs, there is increased difficulty in storing all information in memory. This approach allows users to abstract away the memory constraint difficulties while maximizing performance.
|
||||
|
||||
Future work includes performance and size comparisons to available C/R libraries. This would include implementing SCR, BLCR, and/or DMTCP and measuring their respective checkpoint times and sizes, as well as time taken to restart. This timing information can then be compared to the checkpoint and restart time presented by this work. Future work could also include new optimization techniques. Additional investigations can provide insight on techniques for reducing the runtime of database queries, PostgreSQL database settings to alter or enable, or communication strategies between distributed nodes. Other work can involve alternative approaches at C/R. This work made use of PostgreSQL since it was already incorporated into RAGE, but future work can look toward alternatives. Filesystem C/R approaches can be investigated to determine possible advantages over a dedicated database. One other route for future work involves identifying the checkpointing interval. The work presented by the authors of \cite{CR-Simple} discusses a multitude of options for determining an optimal interval. Various options presented in their work can be implemented, along with their closed-form solution for identifying a default checkpointing interval that can be built into RAGE.
|
||||
|
||||
%\bibliographyp
|
||||
\bibliography{Bibliography}
|
||||
\bibliographystyle{ieeetr}
|
||||
|
||||
\end{document}
|
||||
145
SoutheastCon/Original Submission/images/checkpoint
Normal file
145
SoutheastCon/Original Submission/images/checkpoint
Normal file
@ -0,0 +1,145 @@
|
||||
<mxfile host="app.diagrams.net" modified="2023-04-23T21:47:10.713Z" agent="Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36" etag="V_daboJY1e5bZW8QE-ZE" version="21.2.1" type="device">
|
||||
<diagram name="Page-1" id="Bw8pLGF7ut9QKwLMz9FI">
|
||||
<mxGraphModel dx="1914" dy="993" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="850" pageHeight="1100" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-1" value="<font style="font-size: 19px;">0</font>" style="ellipse;whiteSpace=wrap;html=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="360" y="150" width="100" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-2" value="<font style="font-size: 19px;">1</font>" style="ellipse;whiteSpace=wrap;html=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="240" y="230" width="100" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-3" value="<font style="font-size: 19px;">3</font>" style="ellipse;whiteSpace=wrap;html=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="480" y="230" width="100" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-4" value="<font style="font-size: 19px;">2</font>" style="ellipse;whiteSpace=wrap;html=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="360" y="230" width="100" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-7" value="<font style="font-size: 19px;">7</font>" style="ellipse;whiteSpace=wrap;html=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="680" y="310" width="100" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-10" value="<font style="font-size: 19px;">8</font>" style="ellipse;whiteSpace=wrap;html=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="135" y="390" width="100" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-11" value="<font style="font-size: 19px;">9</font>" style="ellipse;whiteSpace=wrap;html=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="265" y="390" width="100" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-12" value="<font style="font-size: 19px;">10</font>" style="ellipse;whiteSpace=wrap;html=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="395" y="390" width="100" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-13" value="<font style="font-size: 19px;">11</font>" style="ellipse;whiteSpace=wrap;html=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="605" y="390" width="100" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-14" value="<font style="font-size: 19px;">12</font>" style="ellipse;whiteSpace=wrap;html=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="735" y="390" width="100" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-16" value="<font style="font-size: 19px;">4</font>" style="ellipse;whiteSpace=wrap;html=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="320" y="310" width="100" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-17" value="<font style="font-size: 19px;">6</font>" style="ellipse;whiteSpace=wrap;html=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="560" y="310" width="100" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-18" value="<font style="font-size: 19px;">5</font>" style="ellipse;whiteSpace=wrap;html=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="440" y="310" width="100" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-19" value="" style="endArrow=classic;html=1;rounded=0;" edge="1" parent="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="409.5" y="200" as="sourcePoint" />
|
||||
<mxPoint x="410" y="230" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-20" value="" style="endArrow=classic;html=1;rounded=0;exitX=0;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="1q9oL-J-YfLs7LFXKfUn-1" target="1q9oL-J-YfLs7LFXKfUn-2">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="230" y="170" as="sourcePoint" />
|
||||
<mxPoint x="230" y="220" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-21" value="" style="endArrow=classic;html=1;rounded=0;exitX=1;exitY=1;exitDx=0;exitDy=0;entryX=0;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="1q9oL-J-YfLs7LFXKfUn-1" target="1q9oL-J-YfLs7LFXKfUn-3">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="240" y="180" as="sourcePoint" />
|
||||
<mxPoint x="240" y="230" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-22" value="" style="endArrow=classic;html=1;rounded=0;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="1q9oL-J-YfLs7LFXKfUn-2" target="1q9oL-J-YfLs7LFXKfUn-16">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="250" y="190" as="sourcePoint" />
|
||||
<mxPoint x="250" y="240" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-23" value="" style="endArrow=classic;html=1;rounded=0;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="1q9oL-J-YfLs7LFXKfUn-4" target="1q9oL-J-YfLs7LFXKfUn-16">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="260" y="200" as="sourcePoint" />
|
||||
<mxPoint x="260" y="250" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-24" value="" style="endArrow=classic;html=1;rounded=0;entryX=0;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" target="1q9oL-J-YfLs7LFXKfUn-18">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="410" y="280" as="sourcePoint" />
|
||||
<mxPoint x="270" y="260" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-25" value="" style="endArrow=classic;html=1;rounded=0;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="1q9oL-J-YfLs7LFXKfUn-3" target="1q9oL-J-YfLs7LFXKfUn-18">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="280" y="220" as="sourcePoint" />
|
||||
<mxPoint x="280" y="270" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-26" value="" style="endArrow=classic;html=1;rounded=0;exitX=0.5;exitY=1;exitDx=0;exitDy=0;" edge="1" parent="1" source="1q9oL-J-YfLs7LFXKfUn-3" target="1q9oL-J-YfLs7LFXKfUn-17">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="290" y="230" as="sourcePoint" />
|
||||
<mxPoint x="290" y="280" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-27" value="" style="endArrow=classic;html=1;rounded=0;entryX=0;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" target="1q9oL-J-YfLs7LFXKfUn-7">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="530" y="280" as="sourcePoint" />
|
||||
<mxPoint x="300" y="290" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-28" value="" style="endArrow=classic;html=1;rounded=0;exitX=0;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="1q9oL-J-YfLs7LFXKfUn-16" target="1q9oL-J-YfLs7LFXKfUn-10">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="310" y="250" as="sourcePoint" />
|
||||
<mxPoint x="310" y="300" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-29" value="" style="endArrow=classic;html=1;rounded=0;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="1q9oL-J-YfLs7LFXKfUn-16" target="1q9oL-J-YfLs7LFXKfUn-11">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="320" y="260" as="sourcePoint" />
|
||||
<mxPoint x="320" y="310" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-30" value="" style="endArrow=classic;html=1;rounded=0;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="1q9oL-J-YfLs7LFXKfUn-18" target="1q9oL-J-YfLs7LFXKfUn-12">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="330" y="270" as="sourcePoint" />
|
||||
<mxPoint x="330" y="320" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-31" value="" style="endArrow=classic;html=1;rounded=0;exitX=0.5;exitY=1;exitDx=0;exitDy=0;" edge="1" parent="1" source="1q9oL-J-YfLs7LFXKfUn-7" target="1q9oL-J-YfLs7LFXKfUn-13">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="340" y="280" as="sourcePoint" />
|
||||
<mxPoint x="340" y="330" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-32" value="" style="endArrow=classic;html=1;rounded=0;exitX=0.5;exitY=1;exitDx=0;exitDy=0;" edge="1" parent="1" source="1q9oL-J-YfLs7LFXKfUn-7" target="1q9oL-J-YfLs7LFXKfUn-14">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="350" y="290" as="sourcePoint" />
|
||||
<mxPoint x="350" y="340" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-33" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=none;strokeWidth=4;" vertex="1" parent="1">
|
||||
<mxGeometry x="190" y="143" width="610" height="230" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-34" value="<font style="font-size: 19px;">Instance</font>" style="text;html=1;align=center;verticalAlign=middle;resizable=0;points=[];autosize=1;strokeColor=none;fillColor=none;" vertex="1" parent="1">
|
||||
<mxGeometry x="520" y="103" width="100" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-35" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=none;strokeWidth=3;dashed=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="120" y="380" width="750" height="80" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="1q9oL-J-YfLs7LFXKfUn-36" value="<font style="font-size: 19px;">Frontier</font>" style="text;html=1;align=center;verticalAlign=middle;resizable=0;points=[];autosize=1;strokeColor=none;fillColor=none;" vertex="1" parent="1">
|
||||
<mxGeometry x="430" y="463" width="90" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
</mxfile>
|
||||
BIN
SoutheastCon/Original Submission/images/schri1.png
Normal file
BIN
SoutheastCon/Original Submission/images/schri1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
BIN
SoutheastCon/Original Submission/images/schri2.png
Normal file
BIN
SoutheastCon/Original Submission/images/schri2.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
BIN
SoutheastCon/Original Submission/images/schri3.png
Normal file
BIN
SoutheastCon/Original Submission/images/schri3.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
BIN
SoutheastCon/Original Submission/images/schri4.png
Normal file
BIN
SoutheastCon/Original Submission/images/schri4.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
BIN
SoutheastCon/Original Submission/images/schri5.png
Normal file
BIN
SoutheastCon/Original Submission/images/schri5.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 6.9 MiB |
BIN
SoutheastCon/Original Submission/images/schri6.jpg
Normal file
BIN
SoutheastCon/Original Submission/images/schri6.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 5.7 KiB |
BIN
SoutheastCon/Template/Conference-LaTeX-template_10-17-19/.DS_Store
vendored
Normal file
BIN
SoutheastCon/Template/Conference-LaTeX-template_10-17-19/.DS_Store
vendored
Normal file
Binary file not shown.
File diff suppressed because it is too large
Load Diff
Binary file not shown.
Binary file not shown.
@ -0,0 +1,288 @@
|
||||
\documentclass[conference]{IEEEtran}
|
||||
\IEEEoverridecommandlockouts
|
||||
% The preceding line is only needed to identify funding in the first footnote. If that is unneeded, please comment it out.
|
||||
\usepackage{cite}
|
||||
\usepackage{amsmath,amssymb,amsfonts}
|
||||
\usepackage{algorithmic}
|
||||
\usepackage{graphicx}
|
||||
\usepackage{textcomp}
|
||||
\usepackage{xcolor}
|
||||
\def\BibTeX{{\rm B\kern-.05em{\sc i\kern-.025em b}\kern-.08em
|
||||
T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}}
|
||||
\begin{document}
|
||||
|
||||
\title{Conference Paper Title*\\
|
||||
{\footnotesize \textsuperscript{*}Note: Sub-titles are not captured in Xplore and
|
||||
should not be used}
|
||||
\thanks{Identify applicable funding agency here. If none, delete this.}
|
||||
}
|
||||
|
||||
\author{\IEEEauthorblockN{1\textsuperscript{st} Given Name Surname}
|
||||
\IEEEauthorblockA{\textit{dept. name of organization (of Aff.)} \\
|
||||
\textit{name of organization (of Aff.)}\\
|
||||
City, Country \\
|
||||
email address or ORCID}
|
||||
\and
|
||||
\IEEEauthorblockN{2\textsuperscript{nd} Given Name Surname}
|
||||
\IEEEauthorblockA{\textit{dept. name of organization (of Aff.)} \\
|
||||
\textit{name of organization (of Aff.)}\\
|
||||
City, Country \\
|
||||
email address or ORCID}
|
||||
\and
|
||||
\IEEEauthorblockN{3\textsuperscript{rd} Given Name Surname}
|
||||
\IEEEauthorblockA{\textit{dept. name of organization (of Aff.)} \\
|
||||
\textit{name of organization (of Aff.)}\\
|
||||
City, Country \\
|
||||
email address or ORCID}
|
||||
\and
|
||||
\IEEEauthorblockN{4\textsuperscript{th} Given Name Surname}
|
||||
\IEEEauthorblockA{\textit{dept. name of organization (of Aff.)} \\
|
||||
\textit{name of organization (of Aff.)}\\
|
||||
City, Country \\
|
||||
email address or ORCID}
|
||||
\and
|
||||
\IEEEauthorblockN{5\textsuperscript{th} Given Name Surname}
|
||||
\IEEEauthorblockA{\textit{dept. name of organization (of Aff.)} \\
|
||||
\textit{name of organization (of Aff.)}\\
|
||||
City, Country \\
|
||||
email address or ORCID}
|
||||
\and
|
||||
\IEEEauthorblockN{6\textsuperscript{th} Given Name Surname}
|
||||
\IEEEauthorblockA{\textit{dept. name of organization (of Aff.)} \\
|
||||
\textit{name of organization (of Aff.)}\\
|
||||
City, Country \\
|
||||
email address or ORCID}
|
||||
}
|
||||
|
||||
\maketitle
|
||||
|
||||
\begin{abstract}
|
||||
This document is a model and instructions for \LaTeX.
|
||||
This and the IEEEtran.cls file define the components of your paper [title, text, heads, etc.]. *CRITICAL: Do Not Use Symbols, Special Characters, Footnotes,
|
||||
or Math in Paper Title or Abstract.
|
||||
\end{abstract}
|
||||
|
||||
\begin{IEEEkeywords}
|
||||
component, formatting, style, styling, insert
|
||||
\end{IEEEkeywords}
|
||||
|
||||
\section{Introduction}
|
||||
This document is a model and instructions for \LaTeX.
|
||||
Please observe the conference page limits.
|
||||
|
||||
\section{Ease of Use}
|
||||
|
||||
\subsection{Maintaining the Integrity of the Specifications}
|
||||
|
||||
The IEEEtran class file is used to format your paper and style the text. All margins,
|
||||
column widths, line spaces, and text fonts are prescribed; please do not
|
||||
alter them. You may note peculiarities. For example, the head margin
|
||||
measures proportionately more than is customary. This measurement
|
||||
and others are deliberate, using specifications that anticipate your paper
|
||||
as one part of the entire proceedings, and not as an independent document.
|
||||
Please do not revise any of the current designations.
|
||||
|
||||
\section{Prepare Your Paper Before Styling}
|
||||
Before you begin to format your paper, first write and save the content as a
|
||||
separate text file. Complete all content and organizational editing before
|
||||
formatting. Please note sections \ref{AA}--\ref{SCM} below for more information on
|
||||
proofreading, spelling and grammar.
|
||||
|
||||
Keep your text and graphic files separate until after the text has been
|
||||
formatted and styled. Do not number text heads---{\LaTeX} will do that
|
||||
for you.
|
||||
|
||||
\subsection{Abbreviations and Acronyms}\label{AA}
|
||||
Define abbreviations and acronyms the first time they are used in the text,
|
||||
even after they have been defined in the abstract. Abbreviations such as
|
||||
IEEE, SI, MKS, CGS, ac, dc, and rms do not have to be defined. Do not use
|
||||
abbreviations in the title or heads unless they are unavoidable.
|
||||
|
||||
\subsection{Units}
|
||||
\begin{itemize}
|
||||
\item Use either SI (MKS) or CGS as primary units. (SI units are encouraged.) English units may be used as secondary units (in parentheses). An exception would be the use of English units as identifiers in trade, such as ``3.5-inch disk drive''.
|
||||
\item Avoid combining SI and CGS units, such as current in amperes and magnetic field in oersteds. This often leads to confusion because equations do not balance dimensionally. If you must use mixed units, clearly state the units for each quantity that you use in an equation.
|
||||
\item Do not mix complete spellings and abbreviations of units: ``Wb/m\textsuperscript{2}'' or ``webers per square meter'', not ``webers/m\textsuperscript{2}''. Spell out units when they appear in text: ``. . . a few henries'', not ``. . . a few H''.
|
||||
\item Use a zero before decimal points: ``0.25'', not ``.25''. Use ``cm\textsuperscript{3}'', not ``cc''.)
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Equations}
|
||||
Number equations consecutively. To make your
|
||||
equations more compact, you may use the solidus (~/~), the exp function, or
|
||||
appropriate exponents. Italicize Roman symbols for quantities and variables,
|
||||
but not Greek symbols. Use a long dash rather than a hyphen for a minus
|
||||
sign. Punctuate equations with commas or periods when they are part of a
|
||||
sentence, as in:
|
||||
\begin{equation}
|
||||
a+b=\gamma\label{eq}
|
||||
\end{equation}
|
||||
|
||||
Be sure that the
|
||||
symbols in your equation have been defined before or immediately following
|
||||
the equation. Use ``\eqref{eq}'', not ``Eq.~\eqref{eq}'' or ``equation \eqref{eq}'', except at
|
||||
the beginning of a sentence: ``Equation \eqref{eq} is . . .''
|
||||
|
||||
\subsection{\LaTeX-Specific Advice}
|
||||
|
||||
Please use ``soft'' (e.g., \verb|\eqref{Eq}|) cross references instead
|
||||
of ``hard'' references (e.g., \verb|(1)|). That will make it possible
|
||||
to combine sections, add equations, or change the order of figures or
|
||||
citations without having to go through the file line by line.
|
||||
|
||||
Please don't use the \verb|{eqnarray}| equation environment. Use
|
||||
\verb|{align}| or \verb|{IEEEeqnarray}| instead. The \verb|{eqnarray}|
|
||||
environment leaves unsightly spaces around relation symbols.
|
||||
|
||||
Please note that the \verb|{subequations}| environment in {\LaTeX}
|
||||
will increment the main equation counter even when there are no
|
||||
equation numbers displayed. If you forget that, you might write an
|
||||
article in which the equation numbers skip from (17) to (20), causing
|
||||
the copy editors to wonder if you've discovered a new method of
|
||||
counting.
|
||||
|
||||
{\BibTeX} does not work by magic. It doesn't get the bibliographic
|
||||
data from thin air but from .bib files. If you use {\BibTeX} to produce a
|
||||
bibliography you must send the .bib files.
|
||||
|
||||
{\LaTeX} can't read your mind. If you assign the same label to a
|
||||
subsubsection and a table, you might find that Table I has been cross
|
||||
referenced as Table IV-B3.
|
||||
|
||||
{\LaTeX} does not have precognitive abilities. If you put a
|
||||
\verb|\label| command before the command that updates the counter it's
|
||||
supposed to be using, the label will pick up the last counter to be
|
||||
cross referenced instead. In particular, a \verb|\label| command
|
||||
should not go before the caption of a figure or a table.
|
||||
|
||||
Do not use \verb|\nonumber| inside the \verb|{array}| environment. It
|
||||
will not stop equation numbers inside \verb|{array}| (there won't be
|
||||
any anyway) and it might stop a wanted equation number in the
|
||||
surrounding equation.
|
||||
|
||||
\subsection{Some Common Mistakes}\label{SCM}
|
||||
\begin{itemize}
|
||||
\item The word ``data'' is plural, not singular.
|
||||
\item The subscript for the permeability of vacuum $\mu_{0}$, and other common scientific constants, is zero with subscript formatting, not a lowercase letter ``o''.
|
||||
\item In American English, commas, semicolons, periods, question and exclamation marks are located within quotation marks only when a complete thought or name is cited, such as a title or full quotation. When quotation marks are used, instead of a bold or italic typeface, to highlight a word or phrase, punctuation should appear outside of the quotation marks. A parenthetical phrase or statement at the end of a sentence is punctuated outside of the closing parenthesis (like this). (A parenthetical sentence is punctuated within the parentheses.)
|
||||
\item A graph within a graph is an ``inset'', not an ``insert''. The word alternatively is preferred to the word ``alternately'' (unless you really mean something that alternates).
|
||||
\item Do not use the word ``essentially'' to mean ``approximately'' or ``effectively''.
|
||||
\item In your paper title, if the words ``that uses'' can accurately replace the word ``using'', capitalize the ``u''; if not, keep using lower-cased.
|
||||
\item Be aware of the different meanings of the homophones ``affect'' and ``effect'', ``complement'' and ``compliment'', ``discreet'' and ``discrete'', ``principal'' and ``principle''.
|
||||
\item Do not confuse ``imply'' and ``infer''.
|
||||
\item The prefix ``non'' is not a word; it should be joined to the word it modifies, usually without a hyphen.
|
||||
\item There is no period after the ``et'' in the Latin abbreviation ``et al.''.
|
||||
\item The abbreviation ``i.e.'' means ``that is'', and the abbreviation ``e.g.'' means ``for example''.
|
||||
\end{itemize}
|
||||
An excellent style manual for science writers is \cite{b7}.
|
||||
|
||||
\subsection{Authors and Affiliations}
|
||||
\textbf{The class file is designed for, but not limited to, six authors.} A
|
||||
minimum of one author is required for all conference articles. Author names
|
||||
should be listed starting from left to right and then moving down to the
|
||||
next line. This is the author sequence that will be used in future citations
|
||||
and by indexing services. Names should not be listed in columns nor group by
|
||||
affiliation. Please keep your affiliations as succinct as possible (for
|
||||
example, do not differentiate among departments of the same organization).
|
||||
|
||||
\subsection{Identify the Headings}
|
||||
Headings, or heads, are organizational devices that guide the reader through
|
||||
your paper. There are two types: component heads and text heads.
|
||||
|
||||
Component heads identify the different components of your paper and are not
|
||||
topically subordinate to each other. Examples include Acknowledgments and
|
||||
References and, for these, the correct style to use is ``Heading 5''. Use
|
||||
``figure caption'' for your Figure captions, and ``table head'' for your
|
||||
table title. Run-in heads, such as ``Abstract'', will require you to apply a
|
||||
style (in this case, italic) in addition to the style provided by the drop
|
||||
down menu to differentiate the head from the text.
|
||||
|
||||
Text heads organize the topics on a relational, hierarchical basis. For
|
||||
example, the paper title is the primary text head because all subsequent
|
||||
material relates and elaborates on this one topic. If there are two or more
|
||||
sub-topics, the next level head (uppercase Roman numerals) should be used
|
||||
and, conversely, if there are not at least two sub-topics, then no subheads
|
||||
should be introduced.
|
||||
|
||||
\subsection{Figures and Tables}
|
||||
\paragraph{Positioning Figures and Tables} Place figures and tables at the top and
|
||||
bottom of columns. Avoid placing them in the middle of columns. Large
|
||||
figures and tables may span across both columns. Figure captions should be
|
||||
below the figures; table heads should appear above the tables. Insert
|
||||
figures and tables after they are cited in the text. Use the abbreviation
|
||||
``Fig.~\ref{fig}'', even at the beginning of a sentence.
|
||||
|
||||
\begin{table}[htbp]
|
||||
\caption{Table Type Styles}
|
||||
\begin{center}
|
||||
\begin{tabular}{|c|c|c|c|}
|
||||
\hline
|
||||
\textbf{Table}&\multicolumn{3}{|c|}{\textbf{Table Column Head}} \\
|
||||
\cline{2-4}
|
||||
\textbf{Head} & \textbf{\textit{Table column subhead}}& \textbf{\textit{Subhead}}& \textbf{\textit{Subhead}} \\
|
||||
\hline
|
||||
copy& More table copy$^{\mathrm{a}}$& & \\
|
||||
\hline
|
||||
\multicolumn{4}{l}{$^{\mathrm{a}}$Sample of a Table footnote.}
|
||||
\end{tabular}
|
||||
\label{tab1}
|
||||
\end{center}
|
||||
\end{table}
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\centerline{\includegraphics{fig1.png}}
|
||||
\caption{Example of a figure caption.}
|
||||
\label{fig}
|
||||
\end{figure}
|
||||
|
||||
Figure Labels: Use 8 point Times New Roman for Figure labels. Use words
|
||||
rather than symbols or abbreviations when writing Figure axis labels to
|
||||
avoid confusing the reader. As an example, write the quantity
|
||||
``Magnetization'', or ``Magnetization, M'', not just ``M''. If including
|
||||
units in the label, present them within parentheses. Do not label axes only
|
||||
with units. In the example, write ``Magnetization (A/m)'' or ``Magnetization
|
||||
\{A[m(1)]\}'', not just ``A/m''. Do not label axes with a ratio of
|
||||
quantities and units. For example, write ``Temperature (K)'', not
|
||||
``Temperature/K''.
|
||||
|
||||
\section*{Acknowledgment}
|
||||
|
||||
The preferred spelling of the word ``acknowledgment'' in America is without
|
||||
an ``e'' after the ``g''. Avoid the stilted expression ``one of us (R. B.
|
||||
G.) thanks $\ldots$''. Instead, try ``R. B. G. thanks$\ldots$''. Put sponsor
|
||||
acknowledgments in the unnumbered footnote on the first page.
|
||||
|
||||
\section*{References}
|
||||
|
||||
Please number citations consecutively within brackets \cite{b1}. The
|
||||
sentence punctuation follows the bracket \cite{b2}. Refer simply to the reference
|
||||
number, as in \cite{b3}---do not use ``Ref. \cite{b3}'' or ``reference \cite{b3}'' except at
|
||||
the beginning of a sentence: ``Reference \cite{b3} was the first $\ldots$''
|
||||
|
||||
Number footnotes separately in superscripts. Place the actual footnote at
|
||||
the bottom of the column in which it was cited. Do not put footnotes in the
|
||||
abstract or reference list. Use letters for table footnotes.
|
||||
|
||||
Unless there are six authors or more give all authors' names; do not use
|
||||
``et al.''. Papers that have not been published, even if they have been
|
||||
submitted for publication, should be cited as ``unpublished'' \cite{b4}. Papers
|
||||
that have been accepted for publication should be cited as ``in press'' \cite{b5}.
|
||||
Capitalize only the first word in a paper title, except for proper nouns and
|
||||
element symbols.
|
||||
|
||||
For papers published in translation journals, please give the English
|
||||
citation first, followed by the original foreign-language citation \cite{b6}.
|
||||
|
||||
\begin{thebibliography}{00}
|
||||
\bibitem{b1} G. Eason, B. Noble, and I. N. Sneddon, ``On certain integrals of Lipschitz-Hankel type involving products of Bessel functions,'' Phil. Trans. Roy. Soc. London, vol. A247, pp. 529--551, April 1955.
|
||||
\bibitem{b2} J. Clerk Maxwell, A Treatise on Electricity and Magnetism, 3rd ed., vol. 2. Oxford: Clarendon, 1892, pp.68--73.
|
||||
\bibitem{b3} I. S. Jacobs and C. P. Bean, ``Fine particles, thin films and exchange anisotropy,'' in Magnetism, vol. III, G. T. Rado and H. Suhl, Eds. New York: Academic, 1963, pp. 271--350.
|
||||
\bibitem{b4} K. Elissa, ``Title of paper if known,'' unpublished.
|
||||
\bibitem{b5} R. Nicole, ``Title of paper with only first word capitalized,'' J. Name Stand. Abbrev., in press.
|
||||
\bibitem{b6} Y. Yorozu, M. Hirano, K. Oka, and Y. Tagawa, ``Electron spectroscopy studies on magneto-optical media and plastic substrate interface,'' IEEE Transl. J. Magn. Japan, vol. 2, pp. 740--741, August 1987 [Digests 9th Annual Conf. Magnetics Japan, p. 301, 1982].
|
||||
\bibitem{b7} M. Young, The Technical Writer's Handbook. Mill Valley, CA: University Science, 1989.
|
||||
\end{thebibliography}
|
||||
\vspace{12pt}
|
||||
\color{red}
|
||||
IEEE conference templates contain guidance text for composing and formatting conference papers. Please ensure that all template text is removed from your conference paper prior to submission to the conference. Failure to remove the template text from your paper may result in your paper not being published.
|
||||
|
||||
\end{document}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 4.4 KiB |
Loading…
x
Reference in New Issue
Block a user