diff --git a/batch/autoassign.php b/batch/autoassign.php
index 4c946d44a..1fe5b798d 100644
--- a/batch/autoassign.php
+++ b/batch/autoassign.php
@@ -96,7 +96,7 @@ function run() {
}
$pids = $srch->paper_ids();
if (empty($pids)) {
- throw new CommandLineException("No papers match that search");
+ throw new CommandLineException("No applications match that search");
}
if (empty($this->pcc)) {
@@ -159,8 +159,8 @@ static function make_args($argv) {
"config: !",
"dry-run,d Do not perform assignment; output CSV instead.",
"a:,autoassigner: =AA Use autoassigner AA.",
- "q:,search: =QUERY Use papers matching QUERY.",
- "all Search all papers (default is to search submitted papers).",
+ "q:,search: =QUERY Use applications matching QUERY.",
+ "all Search all applications (default is to search submitted applications).",
"u[],user[] =USER Include users matching USER (`-USER` excludes).",
"c:,count: {n} =N Set `count` parameter to N.",
"t:,type: =TYPE Set `type`/`rtype` parameter to TYPE.",
diff --git a/batch/paperjson.php b/batch/paperjson.php
index a843af69f..b4b298aec 100644
--- a/batch/paperjson.php
+++ b/batch/paperjson.php
@@ -93,7 +93,7 @@ static function make_args($argv) {
"t:,type: =COLLECTION Search COLLECTION ‘s’ or ‘all’ [submitted]",
"1,single Output first matching paper rather than an array",
"help,h"
- )->description("Output a JSON file with papers matching SEARCH.
+ )->description("Output a JSON file with applications matching SEARCH.
Usage: php batch/paperjson.php [-t all] [-1] [SEARCH...]")
->helpopt("help")
->parse($argv);
diff --git a/batch/reviewcsv.php b/batch/reviewcsv.php
index 2a0967df0..6063d209a 100644
--- a/batch/reviewcsv.php
+++ b/batch/reviewcsv.php
@@ -304,7 +304,7 @@ static function run_args($argv) {
"no-score Omit score fields",
"no-header Omit CSV header",
"format: =FMT Only output text fields with format FMT"
- )->description("Output CSV containing all reviews for papers matching QUERY.
+ )->description("Output CSV containing all reviews for applications matching QUERY.
Usage: php batch/reviewcsv.php [-acx] [QUERY...]")
->helpopt("help")
->parse($argv);
diff --git a/batch/savepapers.php b/batch/savepapers.php
index 24f133bfc..722ba5b89 100644
--- a/batch/savepapers.php
+++ b/batch/savepapers.php
@@ -293,11 +293,11 @@ static function run_args($argv) {
"ignore-errors Don’t exit after first error",
"disable-users,disable Disable all newly created users",
"ignore-pid Ignore `pid` JSON elements",
- "match-title Match papers by title if no `pid`",
+ "match-title Match applications by title if no `pid`",
"add-topics Add all referenced topics to conference",
"no-log Don’t modify the action log"
)->helpopt("help")
- ->description("Change papers as specified by FILE, a JSON object or array of objects.
+ ->description("Change applications as specified by FILE, a JSON object or array of objects.
Usage: php batch/savepapers.php [OPTIONS] [FILE]")
->maxarg(1)
->parse($argv);
diff --git a/batch/search.php b/batch/search.php
index 15a086e80..3ed8613d6 100644
--- a/batch/search.php
+++ b/batch/search.php
@@ -68,7 +68,7 @@ function run() {
static function help() {
fwrite(STDOUT, "Usage: php batch/search.php [-n CONFID] [-t COLLECTION] [-f FIELD]+ [QUERY...]
-Output a CSV file containing the FIELDs for the papers matching QUERY.
+Output a CSV file containing the FIELDs for the applications matching QUERY.
Options include:
-t, --type COLLECTION Search COLLECTION “s” (submitted) or “all” [s].
diff --git a/docker/hotcrp-options.php b/docker/hotcrp-options.php
index 56c5e7677..b46c675e2 100644
--- a/docker/hotcrp-options.php
+++ b/docker/hotcrp-options.php
@@ -41,7 +41,7 @@
// number. Examples: "SIGCOMM 2007", "HotNets V".
// longName Longer name of the conference. Example: "ACM SIGCOMM
// 2007 Conference".
-// downloadPrefix Prefix for downloaded files, such as papers; should
+// downloadPrefix Prefix for downloaded files, such as applications; should
// end in a dash. Example: "hotnets5-". Defaults to
// $Opt["dbName"] plus a dash.
// paperSite [OPTIONAL] URL for this HotCRP installation. Used in
@@ -121,7 +121,7 @@
// PAPER STORAGE
//
-// docstore Set to true to serve papers and other downloads from a
+// docstore Set to true to serve applications and other downloads from a
// cache on the local filesystem. By default this cache is
// created in the "docs" directory. You can also set
// $Opt["docstore"] to a directory name.
@@ -131,7 +131,7 @@
// s3_bucket Amazon S3 bucket name to store paper submissions.
// s3_key Amazon AWS access key ID (used for S3).
// s3_secret Amazon AWS secret access key (used for S3).
-// dbNoPapers Set to true to not store papers in the database.
+// dbNoPapers Set to true to not store applications in the database.
// Requires filestore, S3 storage, or both.
@@ -186,7 +186,7 @@
// strictJavascript If true, send Javascript with "use strict".
// hideManager If set, PC members are not shown paper managers.
// disableCapabilities If set, emails to authors will not have a
-// token enabling them to view their papers without logging in.
+// token enabling them to view their applications without logging in.
$Opt["smartScoreCompare"] = true;
diff --git a/etc/distoptions.php b/etc/distoptions.php
index b3690a1a2..62fc2c4e2 100644
--- a/etc/distoptions.php
+++ b/etc/distoptions.php
@@ -35,7 +35,7 @@
// number. Examples: "SIGCOMM 2007", "HotNets V".
// longName Longer name of the conference. Example: "ACM SIGCOMM
// 2007 Conference".
-// downloadPrefix Prefix for downloaded files, such as papers; should
+// downloadPrefix Prefix for downloaded files, such as applications; should
// end in a dash. Example: "hotnets5-". Defaults to
// $Opt["dbName"] plus a dash.
// paperSite [OPTIONAL] URL for this HotCRP installation. Used in
@@ -111,7 +111,7 @@
// PAPER STORAGE
//
-// docstore Set to true to serve papers and other downloads from a
+// docstore Set to true to serve applications and other downloads from a
// cache on the local filesystem. By default this cache is
// created in the "docs" directory. You can also set
// $Opt["docstore"] to a directory name.
@@ -121,7 +121,7 @@
// s3_bucket Amazon S3 bucket name to store paper submissions.
// s3_key Amazon AWS access key ID (used for S3).
// s3_secret Amazon AWS secret access key (used for S3).
-// dbNoPapers Set to true to not store papers in the database.
+// dbNoPapers Set to true to not store applications in the database.
// Requires filestore, S3 storage, or both.
@@ -176,7 +176,7 @@
// strictJavascript If true, send Javascript with "use strict".
// hideManager If set, PC members are not shown paper managers.
// disableCapabilities If set, emails to authors will not have a
-// token enabling them to view their papers without logging in.
+// token enabling them to view their applications without logging in.
$Opt["smartScoreCompare"] = true;
diff --git a/etc/helptopics.json b/etc/helptopics.json
index 7f11597c1..455d550cd 100644
--- a/etc/helptopics.json
+++ b/etc/helptopics.json
@@ -280,13 +280,13 @@
{ "name": "revrate", "alias": "reviewratings" },
{
"name": "votetags", "title": "Voting",
- "description": "<0>PC members can vote for papers using tags.",
+ "description": "<0>PC members can vote for applications using tags.",
"print_function": "VoteTags_HelpTopic::print",
"order": 8000
},
{
"name": "ranking", "title": "Ranking",
- "description": "<0>PC members can rank papers using tags.",
+ "description": "<0>PC members can rank applications using tags.",
"print_function": "Ranking_HelpTopic::print",
"order": 9000
},
diff --git a/etc/mailtemplates.json b/etc/mailtemplates.json
index 2fd48df8f..8a027b714 100644
--- a/etc/mailtemplates.json
+++ b/etc/mailtemplates.json
@@ -725,7 +725,7 @@
"* Title: %TITLE%\n",
"* Author(s): %OPT(AUTHORS)%\n",
"* Site: %URL(paper, p=%NUMBER%, %AUTHORVIEWCAPABILITY%)%\n\n",
- "%NUMACCEPTED% papers were accepted out of %NUMSUBMITTED% submissions.\n\n",
+ "%NUMACCEPTED% applications were accepted out of %NUMSUBMITTED% submissions.\n\n",
"Visit the submission site for reviews, comments, and related information. Reviews and comments are also included below.\n\n",
"Contact %ADMIN% with any questions or concerns.\n\n",
"%SIGNATURE%\n\n",
diff --git a/etc/msgs.json b/etc/msgs.json
index 5e8dc7da4..2ab1dfa55 100644
--- a/etc/msgs.json
+++ b/etc/msgs.json
@@ -17,7 +17,7 @@
["You can’t register submission #%d yet.", "You can’t register submissions yet.", ["$1<0"]],
["You can’t register submission #%d until %s.", "You can’t register submissions until %2$s.", ["$1<0"]],
- ["%d papers accepted out of %d submitted.", "%d paper accepted out of %d submitted.", ["$1=1"]],
+ ["%d applications accepted out of %d submitted.", "%d application accepted out of %d submitted.", ["$1=1"]],
["%s review deadline", "Review deadline", ["!$1"]],
["%s reviews are requested by this deadline.", "Reviews are requested by this deadline.", ["!$1"]],
["%s review hard deadline", "Review hard deadline", ["!$1"]],
@@ -164,14 +164,14 @@
{"id": "conflictdef", "itext": "This includes past advisors and students, people with the same affiliation, and any recent (~2 years) coauthors and collaborators.", "template": true},
- {"id": "finalsubmit", "itext": "Congratulations! The paper has been accepted. Update the paper’s final version here. {deadline} You may also edit paper contacts, allowing others to view reviews and make changes."},
+ {"id": "finalsubmit", "itext": "Congratulations! The application has been accepted. Update the application’s final version here. {deadline} You may also edit application contacts, allowing others to view reviews and make changes."},
- {"id": "revprefdescription", "itext": "
A review preference is a small integer that indicates how much you want to review a submission. Positive numbers mean you want to review, negative numbers mean you don’t, and −100 means you think you have a conflict. −20 to 20 is a typical range for real preferences; multiple submissions can have the same preference. The automatic assignment algorithm attempts to assign reviews in descending preference order. Different users’ preference values are not compared and need not use the same scale.
\n\n
Select a column heading to sort by that column. Enter preferences in the text boxes or on the paper pages. You may also upload preferences from a text file; see the “Download” and “Upload” links below the paper list.
A review preference is a small integer that indicates how much you want to review a submission. Positive numbers mean you want to review, negative numbers mean you don’t, and −100 means you think you have a conflict. −20 to 20 is a typical range for real preferences; multiple submissions can have the same preference. The automatic assignment algorithm attempts to assign reviews in descending preference order, using topic scores to break ties. Different users’ preference values are not compared and need not use the same scale.
\n\n
The list shows all submissions and their topics (high interest topics, low interest topics). “Topic score” summarizes your interest in the submission’s topics. Select a column heading to sort by that column. Enter preferences in the text boxes or on the paper pages. You may also upload preferences from a text file; see the “Download” and “Upload” links below the paper list.
A review preference is a small integer that indicates how much you want to review a submission. Positive numbers mean you want to review, negative numbers mean you don’t, and −100 means you think you have a conflict. −20 to 20 is a typical range for real preferences; multiple submissions can have the same preference. The automatic assignment algorithm attempts to assign reviews in descending preference order. Different users’ preference values are not compared and need not use the same scale.
\n\n
Select a column heading to sort by that column. Enter preferences in the text boxes or on the application pages. You may also upload preferences from a text file; see the “Download” and “Upload” links below the application list.
A review preference is a small integer that indicates how much you want to review a submission. Positive numbers mean you want to review, negative numbers mean you don’t, and −100 means you think you have a conflict. −20 to 20 is a typical range for real preferences; multiple submissions can have the same preference. The automatic assignment algorithm attempts to assign reviews in descending preference order, using topic scores to break ties. Different users’ preference values are not compared and need not use the same scale.
\n\n
The list shows all submissions and their topics (high interest topics, low interest topics). “Topic score” summarizes your interest in the submission’s topics. Select a column heading to sort by that column. Enter preferences in the text boxes or on the application pages. You may also upload preferences from a text file; see the “Download” and “Upload” links below the application list.
", "require": ["$1"], "format": 5},
- ["external_review_request_description", "External reviewers may view their assigned papers. Before requesting an external review, you should generally check whether they are interested."],
- ["external_review_request_description", "External reviewers may view their assigned papers, including other reviews and the eventual decision. Before requesting an external review, you should generally check whether they are interested.", ["setting.extrev_seerev>0"]],
- ["external_review_request_description", "External reviewers may view their assigned papers, including other reviews and reviewer identities and the eventual decision. Before requesting an external review, you should generally check whether they are interested.", ["setting.extrev_seerev>0", "setting.extrev_seerevid>0"]],
+ ["external_review_request_description", "External reviewers may view their assigned applications. Before requesting an external review, you should generally check whether they are interested."],
+ ["external_review_request_description", "External reviewers may view their assigned applications, including other reviews and the eventual decision. Before requesting an external review, you should generally check whether they are interested.", ["setting.extrev_seerev>0"]],
+ ["external_review_request_description", "External reviewers may view their assigned applications, including other reviews and reviewer identities and the eventual decision. Before requesting an external review, you should generally check whether they are interested.", ["setting.extrev_seerev>0", "setting.extrev_seerevid>0"]],
["(%d more permissions have default values)", "(%d more permission has default value)", ["$1=1"]],
diff --git a/etc/reviewformlibrary.json b/etc/reviewformlibrary.json
index 4472a812f..56bfc646f 100644
--- a/etc/reviewformlibrary.json
+++ b/etc/reviewformlibrary.json
@@ -80,9 +80,9 @@
"type": "radio",
"values": [
"Reject",
- "Weak paper, though I will not fight strongly against it",
- "OK paper, but I will not champion it",
- "Good paper, I will champion it"
+ "Weak application, though I will not fight strongly against it",
+ "OK application, but I will not champion it",
+ "Good application, I will champion it"
],
"start": "A",
"required": true,
@@ -94,11 +94,11 @@
"name": "Overall merit",
"type": "radio",
"values": [
- "Bottom 50% of submitted papers",
- "Top 50% but not top 25% of submitted papers",
- "Top 25% but not top 10% of submitted papers",
- "Top 10% but not top 5% of submitted papers",
- "Top 5% of submitted papers!"
+ "Bottom 50% of submitted applications",
+ "Top 50% but not top 25% of submitted applications",
+ "Top 25% but not top 10% of submitted applications",
+ "Top 10% but not top 5% of submitted applications",
+ "Top 5% of submitted applications!"
],
"required": true,
"visibility": "au"
@@ -146,17 +146,17 @@
"scheme": "orbu"
},
{
- "selector": "Paper summary",
- "name": "Paper summary",
+ "selector": "Application summary",
+ "name": "Application summary",
"type": "text",
- "description": "Please summarize the paper’s main results in your own words. This will frame the review and show that you have understood the paper’s intent.",
+ "description": "Please summarize the application’s main results in your own words. This will frame the review and show that you have understood the application’s intent.",
"visibility": "au"
},
{
- "selector": "Paper summary (shorter description)",
- "name": "Paper summary",
+ "selector": "Applications summary (shorter description)",
+ "name": "Application summary",
"type": "text",
- "description": "Please summarize the paper briefly in your own words.",
+ "description": "Please summarize the application briefly in your own words.",
"visibility": "au"
},
{
@@ -224,14 +224,14 @@
"selector": "Strengths",
"name": "Strengths",
"type": "text",
- "description": "What are the paper’s important strengths? Just a couple sentences, please.",
+ "description": "What are the application’s important strengths? Just a couple sentences, please.",
"visibility": "au"
},
{
"selector": "Weaknesses",
"name": "Weaknesses",
"type": "text",
- "description": "What are the paper’s important weaknesses? Just a couple sentences, please.",
+ "description": "What are the application’s important weaknesses? Just a couple sentences, please.",
"visibility": "au"
}
]
diff --git a/etc/settinginfo.json b/etc/settinginfo.json
index 9e2df69cc..7937e1655 100644
--- a/etc/settinginfo.json
+++ b/etc/settinginfo.json
@@ -487,7 +487,7 @@
},
{
"name": "review_self_assign", "storage": "pcrev_any",
- "title": "PC can review any paper",
+ "title": "PC can review any application",
"type": "checkbox", "initial_value": 1
},
{
@@ -847,7 +847,7 @@
},
{
"name_pattern": "format/$/papersize",
- "title": "PDF format checker paper size",
+ "title": "PDF format checker application size",
"type": "string", "size": 18, "placeholder": "any"
},
{
@@ -959,7 +959,7 @@
},
{
"name": "tag_visibility_conflict", "storage": "tag_seeall",
- "title": "PC can see tags for conflicted papers",
+ "title": "PC can see tags for conflicted applications",
"type": "checkbox"
},
{
diff --git a/scripts/buzzer.js b/scripts/buzzer.js
index 5c9a9daa7..fcb904cf9 100644
--- a/scripts/buzzer.js
+++ b/scripts/buzzer.js
@@ -211,7 +211,7 @@ function do_kiosk() {
hc.push('
Kiosk mode is a discussion status page with no other site privileges. It’s safe to leave a browser in kiosk mode open in the hallway.
');
hc.push('
Kiosk mode will sign your browser out of the site. Do not use kiosk mode on your main browser.
');
hc.push('
These URLs access kiosk mode directly:
');
- hc.push('
With papers
' + escape_html(info.kiosk_urls[1])
+ hc.push('
With applications
' + escape_html(info.kiosk_urls[1])
+ '
Conflicts only
' + escape_html(info.kiosk_urls[0])
+ '
');
if (show_papers)
diff --git a/scripts/script.js b/scripts/script.js
index cb6dca3f2..983eb33cd 100644
--- a/scripts/script.js
+++ b/scripts/script.js
@@ -3287,7 +3287,7 @@ handle_ui.on("js-tracker", function (evt) {
hc.push('PC members without tag ' + vis.substring(1));
hc.push_pop('
');
try {
diff --git a/src/assignmentset.php b/src/assignmentset.php
index d271eb01f..f1251ca8a 100644
--- a/src/assignmentset.php
+++ b/src/assignmentset.php
@@ -1479,7 +1479,7 @@ private function collect_papers($pfield, &$pids, $report_error) {
$val = 1;
}
if (empty($npids) && $report_error) {
- $this->astate->warning("<0>No papers match ‘{$pfield}’");
+ $this->astate->warning("<0>No applications match ‘{$pfield}’");
}
// Implement paper restriction
diff --git a/src/confinvariants.php b/src/confinvariants.php
index ec72339fe..d6bb21d27 100644
--- a/src/confinvariants.php
+++ b/src/confinvariants.php
@@ -102,13 +102,13 @@ function check_summary_settings() {
// `no_papersub` === no submitted papers
$any = $this->invariantq("select paperId from Paper where timeSubmitted>0 limit 1");
if ($any !== !($this->conf->setting("no_papersub") ?? false)) {
- $this->invariant_error("no_papersub", "paper #{0} is submitted but no_papersub is true", "no paper is submitted but no_papersub is false");
+ $this->invariant_error("no_papersub", "application #{0} is submitted but no_papersub is true", "no application is submitted but no_papersub is false");
}
// `paperacc` === any accepted submitted papers
$any = $this->invariantq("select paperId from Paper where outcome>0 and timeSubmitted>0 limit 1");
if ($any !== !!($this->conf->setting("paperacc") ?? false)) {
- $this->invariant_error("paperacc", "paper #{0} is accepted but paperacc is false", "no paper is accepted but paperacc is true");
+ $this->invariant_error("paperacc", "application #{0} is accepted but paperacc is false", "no application is accepted but paperacc is true");
}
// `rev_tokens` === any papers with reviewToken
@@ -155,7 +155,7 @@ function check_papers() {
// submitted xor withdrawn
$any = $this->invariantq("select paperId from Paper where timeSubmitted>0 and timeWithdrawn>0 limit 1");
if ($any) {
- $this->invariant_error("submitted_withdrawn", "paper #{0} is both submitted and withdrawn");
+ $this->invariant_error("submitted_withdrawn", "application #{0} is both submitted and withdrawn");
}
// `dataOverflow` is JSON
@@ -190,7 +190,7 @@ function check_papers() {
// no unknown decisions
$any = $this->invariantq("select paperId, outcome from Paper where outcome?A", $this->conf->decision_set()->ids());
if ($any) {
- $this->invariant_error("unknown_decision", "paper #{0} with unknown outcome #{1}");
+ $this->invariant_error("unknown_decision", "application #{0} with unknown outcome #{1}");
}
return $this;
@@ -364,14 +364,14 @@ function check_documents() {
assert(count($this->irow) === 10);
for ($n = 2; $n !== 6 && $this->irow[$n] === $this->irow[$n + 4]; ++$n) {
}
- $this->invariant_error("paper_denormalization", "bad Paper denormalization, document #{0}.{1} ({{$n}}!={" . ($n+4) . "})");
+ $this->invariant_error("paper_denormalization", "bad Application denormalization, document #{0}.{1} ({{$n}}!={" . ($n+4) . "})");
}
$any = $this->invariantq("select p.paperId, ps.paperStorageId, p.sha1, p.size, p.mimetype, p.timestamp, ps.sha1, ps.size, ps.mimetype, ps.timestamp from Paper p join PaperStorage ps on (ps.paperStorageId=p.finalPaperStorageId) where p.finalPaperStorageId>1 and (p.sha1!=ps.sha1 or p.size!=ps.size or p.mimetype!=ps.mimetype or p.timestamp!=ps.timestamp) limit 1");
if ($any) {
assert(count($this->irow) === 10);
for ($n = 2; $n !== 6 && $this->irow[$n] === $this->irow[$n + 4]; ++$n) {
}
- $this->invariant_error("paper_denormalization", "bad Paper final denormalization, document #{0}.{1} ({{$n}}!={" . ($n+4) . "})");
+ $this->invariant_error("paper_denormalization", "bad Application final denormalization, document #{0}.{1} ({{$n}}!={" . ($n+4) . "})");
}
// filterType is never zero
@@ -505,7 +505,7 @@ function check_document_inactive() {
sort($pids);
$any = $this->invariantq("select s.paperId, s.paperStorageId from PaperStorage s where s.paperStorageId?a and s.inactive limit 1", $pids);
if ($any) {
- $this->invariant_error("inactive", "paper {0} document {1} is inappropriately inactive");
+ $this->invariant_error("inactive", "application {0} document {1} is inappropriately inactive");
}
$oids = $nonempty_oids = [];
@@ -520,19 +520,19 @@ function check_document_inactive() {
if (!empty($oids)) {
$any = $this->invariantq("select o.paperId, o.optionId, s.paperStorageId from PaperOption o join PaperStorage s on (s.paperStorageId=o.value and s.inactive and s.paperStorageId>1) where o.optionId?a limit 1", $oids);
if ($any) {
- $this->invariant_error("inactive", "paper {0} option {1} document {2} is inappropriately inactive");
+ $this->invariant_error("inactive", "application {0} option {1} document {2} is inappropriately inactive");
}
$any = $this->invariantq("select o.paperId, o.optionId, s.paperStorageId, s.paperId from PaperOption o join PaperStorage s on (s.paperStorageId=o.value and s.paperStorageId>1 and s.paperId!=o.paperId) where o.optionId?a limit 1", $oids);
if ($any) {
- $this->invariant_error("paper {0} option {1} document {2} belongs to different paper {3}");
+ $this->invariant_error("application {0} option {1} document {2} belongs to different application {3}");
}
}
if (!empty($nonempty_oids)) {
$any = $this->invariantq("select o.paperId, o.optionId from PaperOption o where o.optionId?a and o.value<=1 limit 1", $nonempty_oids);
if ($any) {
- $this->invariant_error("paper {0} option {1} links to empty document");
+ $this->invariant_error("application {0} option {1} links to empty document");
}
}
diff --git a/src/help/h_chairsguide.php b/src/help/h_chairsguide.php
index c0a447f60..6ff2de895 100644
--- a/src/help/h_chairsguide.php
+++ b/src/help/h_chairsguide.php
@@ -57,7 +57,7 @@ static function print_presubmission(HelpRenderer $hth, $gj) {
Additional fields such as checkboxes, selectors, freeform
text, and uploaded attachments. Checkbox fields might include “Consider
- this paper for the Best Student Paper award” or “Provide this paper to the
+ this application for the Best Student Application award” or “Provide this application to the
European shadow PC.” Attachment fields might include supplemental material.
You can search for submissions with or without each field.
Consider checking ", $hth->search_link("the applications", ["q" => "", "t" => "all"]),
" for anomalies. Withdraw and/or delete duplicates or update details on the ",
- $hth->hotlink("paper pages", "paper"), " (via “Edit paper”).
+ $hth->hotlink("application applications", "paper"), " (via “Edit paper”).
Also consider contacting the authors of ",
$hth->search_link("incomplete submissions", ["q" => "status:unsub", "t" => "all"]),
", especially if a PDF document was uploaded; sometimes a
@@ -101,7 +101,7 @@ static function print_assignments(HelpRenderer $hth, $gj) {
echo "
Check for formatting violations (optional). ",
$hth->hotlink("Search", "search", "q="), "
> Download > Format check will download a summary report. Serious errors
- are also shown on paper pages (problematic PDFs are distinguished by an
+ are also shown on application pages (problematic PDFs are distinguished by an
“X”).
\n";
} else if ($gj->itemid === 3) {
@@ -111,29 +111,29 @@ static function print_assignments(HelpRenderer $hth, $gj) {
} else if ($gj->itemid === 4) {
echo "
", $hth->setting_group_link("Set review policies and deadlines", "reviews"),
", including reviewing deadlines,
- review anonymity, and whether PC members may review any paper
+ review anonymity, and whether PC members may review any application
(usually “yes” is the right answer).
\n";
} else if ($gj->itemid === 5) {
echo "
", $hth->setting_link("Prepare tracks (optional).", "track"),
" Tracks give chairs fine-grained control over PC
- members’ access rights for individual papers. Example situations calling for
+ members’ access rights for individual applications. Example situations calling for
tracks include external review committees, PC-paper review committees, and
multi-track conferences.
\n";
} else if ($gj->itemid === 6) {
echo "
", $hth->hotlink("Collect review preferences from the PC.", "reviewprefs"), "
PC members can enter per-paper review preferences (also known as bids) to
- mark papers they want or don’t want to review. Preferences are integers, typically
+ mark applications they want or don’t want to review. Preferences are integers, typically
in the range −20 to 20; the higher the number, the more desired the review assignment.
Users can either set their preferences ",
$hth->hotlink("all at once", "reviewprefs"), ", or (often more
- convenient) page through the ", $hth->search_link("list of submitted papers", ""),
- " and set their preferences on the ", $hth->hotlink("paper pages", "paper"), ".
+ convenient) page through the ", $hth->search_link("list of submitted applications", ""),
+ " and set their preferences on the ", $hth->hotlink("application applications", "paper"), ".
If desired, review preferences can be collected before the submission
- deadline. Select ", $hth->setting_link("“PC can see all registered papers until submission deadline”", "draft_submission_early_visibility"),
- ", which allows PC members to see abstracts for registered papers that haven’t yet
+ deadline. Select ", $hth->setting_link("“PC can see all registered applications until submission deadline”", "draft_submission_early_visibility"),
+ ", which allows PC members to see abstracts for registered applications that haven’t yet
been submitted.
\n";
} else if ($gj->itemid === 7) {
@@ -143,7 +143,7 @@ static function print_assignments(HelpRenderer $hth, $gj) {
such conflicts.\n";
} else if ($gj->itemid === 8) {
- echo "
", $hth->hotlink("Assign reviews.", "manualassign"), " You can make assignments ", $hth->hotlink("by paper", "assign"), ", ",
+ echo "
", $hth->hotlink("Assign reviews.", "manualassign"), " You can make assignments ", $hth->hotlink("by application", "assign"), ", ",
$hth->hotlink("by PC member", "manualassign"), ", ",
$hth->hotlink("by uploading an assignment file", "bulkassign"), ", or, even easier, ",
$hth->hotlink("automatically", "autoassign"), ". PC
@@ -155,7 +155,7 @@ static function print_assignments(HelpRenderer $hth, $gj) {
The assignment pages apply to all submissions by default. You can
also assign groups of submissions, such as ",
- $hth->search_link("papers with fewer than three completed reviews", "cre:<3"),
+ $hth->search_link("applications with fewer than three completed reviews", "cre:<3"),
".
\n";
} else if ($gj->itemid === 9) {
@@ -166,21 +166,21 @@ static function print_assignments(HelpRenderer $hth, $gj) {
static function print_chair_conflicts(HelpRenderer $hth) {
echo $hth->subhead("Chair conflicts");
echo "
Chairs and system administrators can access any information stored in the
-conference system, including reviewer identities for conflicted papers.
+conference system, including reviewer identities for conflicted applications.
It is easiest to simply accept such conflicts as a fact of life. Chairs
who can’t handle conflicts fairly shouldn’t be chairs. However, HotCRP
does offer other mechanisms for conflicted reviews.
-
First, each paper can be assigned a paper administrator: a PC member
-who manages that paper’s reviewing and discussion. Use the left-hand side of a ",
+
First, each application can be assigned a application administrator: a PC member
+who manages that application’s reviewing and discussion. Use the left-hand side of a ",
$hth->hotlink("submission’s assignment page", "assign"), " to enter its administrator. (You may need to
“Override conflicts” to access the assignment page.)
-Paper administrators have full privilege to assign and view reviews for their
-papers, and can, for example, use the autoassignment tool, but they cannot change
-conference settings. When a paper
+Application administrators have full privilege to assign and view reviews for their
+applications, and can, for example, use the autoassignment tool, but they cannot change
+conference settings. When a application
has an administrator, chair conflicts cannot be overridden.
-
Paper administrators make life easy for PC reviewers and greatly restrict
+
Application administrators make life easy for PC reviewers and greatly restrict
conflicted chairs’ access. Usually this suffices.
For additional privacy, use
review tokens, which are completely anonymous
@@ -190,10 +190,10 @@ static function print_chair_conflicts(HelpRenderer $hth) {
or email address. This reports the token, a short string of letters and
numbers such as “9HDZYUB”. Any user who knows the token can
enter it on HotCRP’s home page, after which the system lets them
-view the paper and anonymously modify the corresponding “Jane Q. Public”
+view the application and anonymously modify the corresponding “Jane Q. Public”
review. True reviewer identities will not appear in HotCRP’s
database or its logs.
-For even more privacy, the paper administrator could collect
+For even more privacy, the application administrator could collect
offline review forms via email and upload them using
review tokens; then even web server access logs store only the
administrator’s identity.
\n\n";
@@ -218,17 +218,17 @@ static function print_premeeting(HelpRenderer $hth, $gj) {
} else if ($gj->itemid === 2) {
echo "
Set ", $hth->setting_link("PC can see review contents", "review_visibility_pc"),
" to “Yes” (optional). This opens up the reviews to the program committee,
- allowing everyone to see scores and read reviews for non-conflicted papers.
- (During most conferences’ review periods, a PC member can see a paper’s reviews
- only after completing their own review for that paper.)
\n";
+ allowing everyone to see scores and read reviews for non-conflicted applications.
+ (During most conferences’ review periods, a PC member can see a application’s reviews
+ only after completing their own review for that application.)\n";
} else if ($gj->itemid === 3) {
- echo "
", $hth->search_link("Examine paper scores", "show:scores"),
+ echo "
", $hth->search_link("Examine application scores", "show:scores"),
", either one at a time or en masse, and decide
- which papers will be discussed. The ", $hth->help_link("tags", "tags"),
- " system can group papers and prepare discussion sets.
+ which applications will be discussed. The ", $hth->help_link("tags", "tags"),
+ " system can group applications and prepare discussion sets.
Use ", $hth->help_link("search keywords", "keywords"), " to, for example,
- find all papers with at least two overall merit ratings of 2 or better.
\n";
+ find all applications with at least two overall merit ratings of 2 or better.
\n";
} else if ($gj->itemid === 4) {
echo "
Assign discussion orders using ", $hth->help_link("tags", "tags#values"),
@@ -240,15 +240,15 @@ static function print_premeeting(HelpRenderer $hth, $gj) {
} else if ($gj->itemid === 5) {
echo "
", $hth->hotlink("Assign discussion leads (optional).", "autoassign"), " Discussion leads are expected to be able to
- summarize the paper and the reviews. You can assign leads either ",
- $hth->hotlink("paper by paper", "assign"), " or ",
+ summarize the application and the reviews. You can assign leads either ",
+ $hth->hotlink("application by application", "assign"), " or ",
$hth->hotlink("automatically", "autoassign"), ".
\n";
} else if ($gj->itemid === 6) {
echo "
", $hth->setting_link("Define decision types (optional).", "decision"),
" By default, HotCRP has two decision types,
“accept” and “reject,” but you can add other types of acceptance and
- rejection, such as “accept as short paper.”
\n";
+ rejection, such as “accept as short application.”
\n";
} else if ($gj->itemid === 7) {
echo "
The night before the meeting, ", $hth->search_link("download all reviews onto a laptop", ""),
@@ -269,9 +269,9 @@ static function print_atmeeting(HelpRenderer $hth, $gj) {
} else if ($gj->itemid === 1) {
echo "
The meeting tracker can keep the PC coordinated
by sharing your browser’s status.
- Search for papers in whatever order you like (you may want an explicit ",
+ Search for applications in whatever order you like (you may want an explicit ",
$hth->help_link("discussion order", "tags#values"), "),
- navigate to the first paper in
+ navigate to the first application in
the order, and select “☟” to activate the tracker in that tab.
As you use that tab to navigate through the order, its current
position is broadcast to all logged-in PC members’ browsers:
@@ -285,15 +285,15 @@ static function print_atmeeting(HelpRenderer $hth, $gj) {
reference.
\n";
} else if ($gj->itemid === 3) {
- echo "
Paper decisions can be recorded on the ",
- $hth->hotlink("paper pages", "review"), " or en masse via ",
+ echo "
Application decisions can be recorded on the ",
+ $hth->hotlink("application applications", "review"), " or en masse via ",
$hth->search_link("search", ""), ". Use ", $hth->setting_link("decision settings", "decision_visibility_author"),
" to expose decisions to PC members if desired.
\n";
} else if ($gj->itemid === 4) {
echo "
Shepherding (optional). If your conference uses
- shepherding for accepted papers, you can assign shepherds either ",
- $hth->hotlink("paper by paper", "paper"), " or ", $hth->hotlink("automatically", "autoassign", "t=accepted"), ".
\n";
+ shepherding for accepted applications, you can assign shepherds either ",
+ $hth->hotlink("application by application", "paper"), " or ", $hth->hotlink("automatically", "autoassign", "t=accepted"), ".\n";
}
}
@@ -326,7 +326,7 @@ static function print_postmeeting(HelpRenderer $hth, $gj) {
themselves.\n";
} else if ($gj->itemid === 5) {
- echo "
", $hth->setting_link("Collect final papers (optional).", "final_open"),
+ echo "
", $hth->setting_link("Collect final applications (optional).", "final_open"),
" If you’re putting together the program
yourself, it can be convenient to collect final versions using HotCRP.
Authors upload final versions just as they did submissions. You can then ",
diff --git a/src/help/h_developer.php b/src/help/h_developer.php
index 4407ed5ca..9735c7dc5 100644
--- a/src/help/h_developer.php
+++ b/src/help/h_developer.php
@@ -93,8 +93,8 @@ function print_settings() {
function print_submissions() {
echo "
The api/paper endpoint accesses conference
submissions. GET calls return paper information; use
-api/PAPERID/paper to return one paper, and
-api/paper?q=SEARCH&t=SEARCHTYPE to return all papers matching
+api/PAPERID/paper to return one application, and
+api/paper?q=SEARCH&t=SEARCHTYPE to return all applications matching
SEARCH.
";
}
}
diff --git a/src/help/h_formulas.php b/src/help/h_formulas.php
index 08176fd1d..2732b7f0d 100644
--- a/src/help/h_formulas.php
+++ b/src/help/h_formulas.php
@@ -5,17 +5,17 @@
class Formulas_HelpTopic {
static function print(HelpRenderer $hth) {
echo "
Program committee members and administrators can search and display formulas
-that calculate properties of paper scores—for instance, the
-standard deviation of papers’ Overall merit scores, or average Overall
+that calculate properties of application scores—for instance, the
+standard deviation of applications’ Overall merit scores, or average Overall
merit among reviewers with high Reviewer expertise.
To display a formula, use a search term such as “",
$hth->search_link("show:var(OveMer)"), "” (show
-the variance in Overall merit scores, along with statistics for all papers).
+the variance in Overall merit scores, along with statistics for all applications).
You can also ", $hth->hotlink("graph formulas", "graph", "group=formula"), ".
To search for a formula, use a search term such as “",
$hth->search_link("formula:var(OveMer)>0.5"), "”
-(select papers with variance in Overall merit greater than 0.5).
+(select applications with variance in Overall merit greater than 0.5).
Or save formulas using ",
$hth->search_link("Search > View options", ["q" => "", "#" => "view"]),
" > Edit formulas.
@@ -77,8 +77,8 @@ static function print(HelpRenderer $hth) {
echo $hth->trow("topics:text", "Number of topics matching text");
}
echo $hth->tgroup("Tags");
- echo $hth->trow("#tagname", "True if this paper has tag tagname");
- echo $hth->trow("tagval:tagname", "The value of tag tagname, or null if this paper doesn’t have that tag");
+ echo $hth->trow("#tagname", "True if this application has tag tagname");
+ echo $hth->trow("tagval:tagname", "The value of tag tagname, or null if this application doesn’t have that tag");
echo $hth->tgroup("Scores");
echo $hth->trow("overall-merit", "This review’s Overall merit score
Only completed reviews are considered.
");
echo $hth->trow("OveMer", "Abbreviations also accepted");
@@ -103,9 +103,9 @@ static function print(HelpRenderer $hth) {
echo $hth->subhead("Aggregate functions");
echo "
Aggregate functions calculate a
-value based on all of a paper’s reviews and/or review preferences.
+value based on all of a application’s reviews and/or review preferences.
For instance, “max(OveMer)” would return the maximum Overall merit score
-assigned to a paper.
+assigned to a application.
An aggregate function’s argument is calculated once per viewable review
or preference.
diff --git a/src/help/h_ranking.php b/src/help/h_ranking.php
index 8140ab5dc..207b8930e 100644
--- a/src/help/h_ranking.php
+++ b/src/help/h_ranking.php
@@ -4,24 +4,24 @@
class Ranking_HelpTopic {
static function print(HelpRenderer $hth) {
- echo "
Paper ranking is a way to extract the PC’s preference order for
-submitted papers. Each PC member ranks the submitted papers, and a voting
+ echo "
Application ranking is a way to extract the PC’s preference order for
+submitted applications. Each PC member ranks the submitted applications, and a voting
algorithm, the Schulze
method by default, combines these rankings into a global preference order.
HotCRP supports ranking through ", $hth->help_link("tags", "tags"), ". The chair chooses
a tag for ranking—“rank” is a good default—and enters it on ",
$hth->setting_link("the settings page", "tag_rank"), ".
-PC members then rank papers using their private versions of this tag,
+PC members then rank applications using their private versions of this tag,
tagging their first preference with “~rank#1”,
their second preference with “~rank#2”,
and so forth. To combine PC rankings into a global preference order, the PC
-chair selects all papers on ", $hth->search_link("the search page", ""),
+chair selects all applications on ", $hth->search_link("the search page", ""),
" and chooses Tags > Calculate rank, entering
“rank” for the tag. At that point, the global rank can be viewed
by ", $hth->search_link("searching for “order:rank”", "order:rank"), ".
-
PC members can enter rankings by reordering rows in a paper list.
+
PC members can enter rankings by reordering rows in a application list.
For example, for rank tag “rank”, PC members should ",
$hth->search_link("search for “editsort:#~rank”", "editsort:#~rank"), ".
Ranks can be entered directly in the text fields, or the rows can be dragged
@@ -36,12 +36,12 @@ static function print(HelpRenderer $hth) {
# Edit the rank order by rearranging this file's lines.
# The first line has the highest rank.
-# Lines that start with \"#\" are ignored. Unranked papers appear at the end
+# Lines that start with \"#\" are ignored. Unranked applications appear at the end
# in lines starting with \"X\", sorted by overall merit. Create a rank by
# removing the \"X\"s and rearranging the lines. A line that starts with \"=\"
-# marks a paper with the same rank as the preceding paper. A line that starts
+# marks a application with the same rank as the preceding application. A line that starts
# with \">>\", \">>>\", and so forth indicates a rank gap between the preceding
-# paper and the current paper. When you are done, upload the file at
+# application and the current application. When you are done, upload the file at
# http://your.site.here.com/offline
Tag: ~rank
diff --git a/src/help/h_search.php b/src/help/h_search.php
index f323b7397..15004717c 100644
--- a/src/help/h_search.php
+++ b/src/help/h_search.php
@@ -13,9 +13,9 @@ static function print(HelpRenderer $hth) {
quicksearch box, this search will jump to #12 directly.
", $hth->help_link("Search keywords", "keywords"), "
let you search specific fields, review scores, and more.
Click on a paper number or title to jump to that paper.
-Search matches are highlighted on paper screens.
-Once on a paper screen use quicklinks
+
Click on a application number or title to jump to that application.
+Search matches are highlighted on application screens.
+Once on a application screen use quicklinks
to navigate through the rest of the search matches.
-
Underneath the paper list is the action area:
+
Underneath the application list is the action area:
Use the checkboxes to select some papers, then choose an action.
+
Use the checkboxes to select some applications, then choose an action.
You can:
-
Download a .zip file with the selected papers.
-
Download all reviews for the selected papers.
+
Download a .zip file with the selected applications.
+
Download all reviews for the selected applications.
Download tab-separated text files with authors, PC
conflicts, review scores, and so forth (some options chairs only).
Add, remove, and define ", $hth->help_link("tags", "tags"), ".
Assign reviewers and mark conflicts (chairs only).
Set decisions (chairs only).
-
Send mail to paper authors or reviewers (chairs only).
+
Send mail to application authors or reviewers (chairs only).
-
Select papers one by one, select in groups by shift-clicking
+
Select applications one by one, select in groups by shift-clicking
the checkboxes, or use the “select all” link.
-The easiest way to tag a set of papers is
+The easiest way to tag a set of applications is
to enter their numbers in the search box, search, “select all,” and add the
tag.
";
@@ -90,13 +90,13 @@ static function print(HelpRenderer $hth) {
Most screens have a quicksearch box in the upper right corner:
" . Ht::img("quicksearchex.png", "[Quicksearch box]") . "
This box supports the full search syntax. Enter
-a paper number, or search terms that match exactly
-one paper, to go directly to that paper.
+a application number, or search terms that match exactly
+one application, to go directly to that application.
-
Paper screens have quicklinks that step through search results:
+
Application screens have quicklinks that step through search results:
" . Ht::img("pageresultsex.png", "[Quicklinks]") . "
-Click on the search description (here, “Submitted papers search”) to return
+Click on the search description (here, “Submitted applications search”) to return
to the search results. On many pages, you can press “j” or
-“k” to go to the previous or next paper in the list.
";
+“k” to go to the previous or next application in the list.";
}
}
diff --git a/src/help/h_tags.php b/src/help/h_tags.php
index 8bd1e5425..361494bbe 100644
--- a/src/help/h_tags.php
+++ b/src/help/h_tags.php
@@ -22,10 +22,10 @@ function print_intro() {
$conflictmsg = " and conflicted PC members";
}
- echo "
PC members and administrators can attach tag names to papers.
-It’s easy to change tags and to list all papers with a given tag,
-and ordered tags preserve a particular paper order.
-Tags also affect color highlighting in paper lists.
+ echo "
PC members and administrators can attach tag names to applications.
+It’s easy to change tags and to list all applications with a given tag,
+and ordered tags preserve a particular application order.
+Tags also affect color highlighting in application lists.
Tags are visible to the PC and hidden from authors$conflictmsg. Twiddle
tags, with names like “#~tag”, are visible only to their creators. Tags
@@ -36,7 +36,7 @@ function print_intro() {
function print_finding() {
$hth = $this->hth;
echo $hth->subhead("Find tags", "find");
- echo "
A paper’s tags are shown like this on the paper page:
+ echo "
A application’s tags are shown like this on the applications page:
",
@@ -51,18 +51,18 @@ function print_finding() {
'
',
"
-
To find all papers with tag “#discuss”:
+
To find all applications with tag “#discuss”:
", $hth->search_form("#discuss"), "
You can also search with “", $hth->search_link("show:tags"), "” to see each
-paper’s tags, or “", $hth->search_link("show:#tagname"), "” to see a particular tag
+application’s tags, or “", $hth->search_link("show:#tagname"), "” to see a particular tag
as a column.
Tags are only shown to PC members and administrators. ";
if ($this->user->isPC) {
if ($this->conf->tag_seeall) {
- echo "Currently PC members can see tags for any paper, including conflicts.";
+ echo "Currently PC members can see tags for any application, including conflicts.";
} else {
echo "They are hidden from conflicted PC members; for instance, if a PC member searches for a tag, the result will never include their conflicts.";
}
@@ -76,14 +76,14 @@ function print_changing() {
echo $hth->subhead("Change tags", "change");
echo "
-
For one paper: Go to a paper page, click the
+
For one application: Go to a application page, click the
“", expander(true), "Tags” expander, and enter tags separated by spaces.
-
For many papers: ", $hth->hotlink("Search", "search"),
-" for papers, select them, and use the action area underneath the
-search list. Add adds tags to the selected papers, Remove removes
-tags from the selected papers, and Define adds the tag to the selected
-papers and removes it from all others.
+
For many applications: ", $hth->hotlink("Search", "search"),
+" for applications, select them, and use the action area underneath the
+search list. Add adds tags to the selected applications, Remove removes
+tags from the selected applications, and Define adds the tag to the selected
+applications and removes it from all others.
", Ht::img("extagssearch.png", "[Setting tags on the search page]", ["width" => 510, "height" => 94]), "
@@ -91,7 +91,7 @@ function print_changing() {
$hth->search_link("edit:tag:tagname"), "” to add tags with checkboxes;
search for “", $hth->search_link("edit:tagval:tagname"), "” to type in tag values; or search for “", $hth->search_link("edit:tags"), "”
-to edit papers’ full tag lists.
+to edit applications’ full tag lists.
@@ -114,31 +114,31 @@ function print_values() {
specific values with search terms like “", $hth->search_link("#discuss#2"),
"” or “", $hth->search_link("#discuss>1"),
"”. A search like “", $hth->search_link("order:#tagname"), "” selects
-papers with the named tag and displays them ordered by that tag’s values.
+applications with the named tag and displays them ordered by that tag’s values.
-
It’s common to assign increasing tag values to a set of papers. Do this
+
It’s common to assign increasing tag values to a set of applications. Do this
using the ", $hth->hotlink("search screen", "search"), ". Search for the
-papers you want, sort them into the right order, select their checkboxes, and
+applications you want, sort them into the right order, select their checkboxes, and
choose Define order in the tag action area. If no sort gives what
-you want, search for the desired paper numbers in order—for instance,
+you want, search for the desired application numbers in order—for instance,
“", $hth->search_link("4 1 12 9"), "”—then Select all and Define
order.
Define order might assign values “#tag#1”,
“#tag#3”, “#tag#6”, and “#tag#7”
-to adjacent papers. The gaps make it harder to infer
-conflicted papers’ positions. (Any given gap might or might not hold a
-conflicted paper.) The Define gapless order action assigns
+to adjacent applications. The gaps make it harder to infer
+conflicted applications’ positions. (Any given gap might or might not hold a
+conflicted application.) The Define gapless order action assigns
strictly sequential values, like “#tag#1”,
“#tag#2”, “#tag#3”, “#tag#4”.
Define order is better for most purposes.
-
To add new papers at the end of an existing discussion order, use Add to
+
To add new applications at the end of an existing discussion order, use Add to
order. To create an order by entering explicit positions and/or dragging
-papers into order, use a search like “", $hth->search_link("editsort:#tagname"), "”.
+applications into order, use a search like “", $hth->search_link("editsort:#tagname"), "”.
The ", $hth->hotlink("autoassigner", "autoassign", "a=discorder"), "
-has special support for creating discussion orders. It tries to group papers
+has special support for creating discussion orders. It tries to group applications
with similar PC conflicts, which can make the meeting run smoother.
Tags “red”, “orange”, “yellow”, “green”, “blue”, “purple”, “gray”, and
-“white” act as highlight colors. For example, papers tagged with “#red” will
-appear red in paper lists (for people
-who can see that tag). Tag a paper “#~red” to make it red only on your display.
+“white” act as highlight colors. For example, applications tagged with “#red” will
+appear red in application lists (for people
+who can see that tag). Tag a application “#~red” to make it red only on your display.
Other styles are available; try “#bold”, “#italic”, “#big”, “#small”, and
“#dim”. The ", $hth->setting_link("settings page", "tag_style"), " can associate other tags
-with colors so that, for example, “" . $hth->search_link("#reject") . "” papers appear
+with colors so that, for example, “" . $hth->search_link("#reject") . "” applications appear
gray.
Skip low-ranked submissions. Mark
low-ranked submissions with tag “#r1reject”, then ask the PC to " .
$this->hth->search_link("search for “#r1reject”", "#r1reject") . ". PC members
-can check the list for papers they’d like to discuss anyway. They can email
-the chairs about such papers, or remove the tag themselves. (You might make
+can check the list for applications they’d like to discuss anyway. They can email
+the chairs about such applications, or remove the tag themselves. (You might make
the “#r1reject” tag chair-only so an evil PC member couldn’t add it to a
-high-ranked paper, but it’s usually better to trust the PC.)
\n";
+high-ranked application, but it’s usually better to trust the PC.)\n";
}
function print_example_controversial() {
- echo "
Mark controversial papers that would benefit from additional review.
+ echo "
Mark controversial applications that would benefit from additional review.
PC members could add the “#controversial” tag when the current reviewers disagree.
A ", $this->hth->hotlink("search", "search", ["q" => "#controversial"]),
" shows where the PC thinks more review is needed.
\n";
}
function print_example_pcpaper() {
- echo "
Mark PC-authored papers for extra scrutiny.
+ echo "
Mark PC-authored applications for extra scrutiny.
First, ", $this->hth->hotlink("search for PC members’ last names in author fields", "search", "t=s&qt=au"), ".
- Check for accidental matches and select the papers with PC members as authors, then use the action area below the search list to add the tag “#pcpaper”.
- A ", $this->hth->hotlink("search", "search", "t=s&q=-%23pcpaper"), " shows papers without PC authors.
\n";
+ Check for accidental matches and select the applications with PC members as authors, then use the action area below the search list to add the tag “#pcpaper”.
+ A ", $this->hth->hotlink("search", "search", "t=s&q=-%23pcpaper"), " shows applications without PC authors.\n";
}
function print_example_allotment() {
$vt = $this->hth->example_tag("allotment");
- echo "
Vote for papers.
+ echo "
Vote for applications.
The chair can define tags used for allotment voting", $this->hth->current_tag_list("allotment"), ".",
$this->hth->change_setting_link("tag_vote_allotment"),
- " Each PC member is assigned an allotment of votes to distribute among papers.
- For instance, if “#{$vt}” were a voting tag with an allotment of 10, then a PC member could assign 5 votes to a paper by adding the twiddle tag “#~{$vt}#5”.
+ " Each PC member is assigned an allotment of votes to distribute among applications.
+ For instance, if “#{$vt}” were a voting tag with an allotment of 10, then a PC member could assign 5 votes to a application by adding the twiddle tag “#~{$vt}#5”.
The system automatically sums PC members’ votes into the public “#{$vt}” tag.
- To search for papers by vote count, search for “", $this->hth->search_link("rorder:#$vt"),
+ To search for applications by vote count, search for “", $this->hth->search_link("rorder:#$vt"),
"”. (", $this->hth->help_link("votetags"), ")
\n";
}
function print_example_rank() {
- echo "
Rank papers.
- Each PC member can set tags indicating their preference ranking for papers.
- For instance, a PC member’s favorite paper would get tag “#~rank#1”, the next favorite “#~rank#2”, and so forth.
+ echo "
Rank applications.
+ Each PC member can set tags indicating their preference ranking for applications.
+ For instance, a PC member’s favorite application would get tag “#~rank#1”, the next favorite “#~rank#2”, and so forth.
The chair can then combine these rankings into a global preference order using a Condorcet method.
(", $this->hth->help_link("ranking"), ")
\n";
}
function print_example_discuss() {
echo "
Define a discussion order.
-Publishing the order lets PC members prepare to discuss upcoming papers.
+Publishing the order lets PC members prepare to discuss upcoming applications.
Define an ordered tag such as “#discuss”, then ask the PC to ", $this->hth->search_link("search for “order:#discuss”", "order:#discuss"), ".
-The PC can now see the order and use quick links to go from paper to paper.";
+The PC can now see the order and use quick links to go from application to application.";
if ($this->user->isPC && !$this->conf->tag_seeall) {
- echo " However, since PC members can’t see tags for conflicted papers, each PC member might see a different list.", $this->hth->change_setting_link("tag_visibility_conflict");
+ echo " However, since PC members can’t see tags for conflicted applications, each PC member might see a different list.", $this->hth->change_setting_link("tag_visibility_conflict");
}
echo "
Some conferences have PC members vote for papers. In
+ echo "
Some conferences have PC members vote for applications. In
allotment voting, each PC member is assigned a vote allotment to
-distribute among unconflicted papers; a PC member might assign one vote to one
+distribute among unconflicted applications; a PC member might assign one vote to one
submission and five to another. In approval voting, each PC member
-can vote for as many papers as they like. The PC’s aggregated vote totals
-might help determine which papers to discuss.
+can vote for as many applications as they like. The PC’s aggregated vote totals
+might help determine which applications to discuss.
HotCRP supports voting through ", $hth->help_link("tags", "tags"), ".
The chair can ", $hth->setting_link("define a set of voting tags", "tag_vote_allotment"),
@@ -27,9 +27,9 @@ static function print(HelpRenderer $hth) {
updates the main “#vote” tag to reflect the total.
(An error is reported when PC members exceed their allotment.)
-
To see papers’ vote counts in a list, search for ",
+
To see applications’ vote counts in a list, search for ",
$hth->search_link("show:#$votetag"),
-". To list the papers with votes, sorted by vote count (most votes first),
+". To list the applications with votes, sorted by vote count (most votes first),
search for ", $hth->search_link("rorder:#$votetag"), " or ",
$hth->search_link("rorder:#$votetag show:#$votetag"), ".
diff --git a/src/listaction.php b/src/listaction.php
index ab291203f..e0ff55e76 100644
--- a/src/listaction.php
+++ b/src/listaction.php
@@ -98,7 +98,7 @@ static private function do_call($name, Contact $user, Qrequest $qreq, $selection
if (!$uf || !Conf::xt_resolve_require($uf) || !is_string($uf->function)) {
return JsonResult::make_error(404, "<0>Action not found");
} else if (($uf->paper ?? false) && $selection->is_empty()) {
- return JsonResult::make_error(400, "<0>No papers selected");
+ return JsonResult::make_error(400, "<0>No applications selected");
} else if ($uf->function[0] === "+") {
$class = substr($uf->function, 1);
/** @phan-suppress-next-line PhanTypeExpectedObjectOrClassName */
@@ -150,7 +150,7 @@ static function pcassignments_csv_data(Contact $user, $pids) {
$texts[] = [];
$texts[] = ["paper" => $prow->paperId,
"action" => "none",
- "title" => "You cannot override your conflict with this paper"];
+ "title" => "You cannot override your conflict with this application"];
} else {
$any_this_paper = false;
foreach ($prow->reviews_as_display() as $rrow) {
diff --git a/src/mailrecipients.php b/src/mailrecipients.php
index c0e886a4a..373291ffd 100644
--- a/src/mailrecipients.php
+++ b/src/mailrecipients.php
@@ -144,8 +144,8 @@ private function enumerate_recipients() {
if ($user->is_manager()) {
$this->recipt_default_message = "authors";
$hide = !$this->conf->has_any_submitted();
- $this->defsel("s", "Contact authors of submitted papers", $hide ? self::F_HIDE : 0);
- $this->defsel("unsub", "Contact authors of unsubmitted papers");
+ $this->defsel("s", "Contact authors of submitted applications", $hide ? self::F_HIDE : 0);
+ $this->defsel("unsub", "Contact authors of unsubmitted applications");
$this->defsel("au", "All contact authors");
$this->dcounts();
@@ -156,10 +156,10 @@ private function enumerate_recipients() {
$this->defsel("dec:{$dec->name}", "Contact authors of " . $dec->name_as(5) . " papers", $hide ? self::F_HIDE : 0);
}
}
- $this->defsel("dec:yes", "Contact authors of accept-class papers", $this->_has_dt[2] ? 0 : self::F_HIDE);
- $this->defsel("dec:no", "Contact authors of reject-class papers", $this->_has_dt[0] ? 0 : self::F_HIDE);
- $this->defsel("dec:none", "Contact authors of undecided papers", $this->_has_dt[1] && ($this->_has_dt[0] || $this->_has_dt[2]) ? 0 : self::F_HIDE);
- $this->defsel("dec:any", "Contact authors of decided papers", self::F_HIDE);
+ $this->defsel("dec:yes", "Contact authors of accept-class applications", $this->_has_dt[2] ? 0 : self::F_HIDE);
+ $this->defsel("dec:no", "Contact authors of reject-class applications", $this->_has_dt[0] ? 0 : self::F_HIDE);
+ $this->defsel("dec:none", "Contact authors of undecided applications", $this->_has_dt[1] && ($this->_has_dt[0] || $this->_has_dt[2]) ? 0 : self::F_HIDE);
+ $this->defsel("dec:any", "Contact authors of decided applications", self::F_HIDE);
$this->defsel("bydec_group_end", null, self::F_GROUP);
$this->recipt_default_message = "reviewers";
diff --git a/src/pages/p_adminhome.php b/src/pages/p_adminhome.php
index d51aadd17..e8e15da4e 100644
--- a/src/pages/p_adminhome.php
+++ b/src/pages/p_adminhome.php
@@ -31,7 +31,7 @@ static function print(Contact $user) {
if (($row = $result->fetch_row())
&& $row[1] < $max_file_size
&& !$conf->opt("dbNoPapers")) {
- $ml[] = new MessageItem(null, "<5>MySQL’s max_allowed_packet setting, which is " . htmlspecialchars($row[1]) . " bytes, is less than the PHP upload file limit, which is {$max_file_size} bytes. You should update max_allowed_packet in the system-wide my.cnf file or the system may not be able to handle large papers", MessageSet::URGENT_NOTE);
+ $ml[] = new MessageItem(null, "<5>MySQL’s max_allowed_packet setting, which is " . htmlspecialchars($row[1]) . " bytes, is less than the PHP upload file limit, which is {$max_file_size} bytes. You should update max_allowed_packet in the system-wide my.cnf file or the system may not be able to handle large applications", MessageSet::URGENT_NOTE);
}
if ($max_file_size < ini_get_bytes(null, "10M")
&& $max_file_size < $conf->upload_max_filesize()) {
@@ -81,7 +81,7 @@ static function print(Contact $user) {
// Any -100 preferences around?
$result = PrefConflict_Autoassigner::query_result($conf, true);
if (($row = $result->fetch_row())) {
- $ml[] = new MessageItem(null, '<5>PC members have indicated paper conflicts (using review preferences of −100 or less) that aren’t yet confirmed. Confirm these conflicts', MessageSet::MARKED_NOTE);
+ $ml[] = new MessageItem(null, '<5>PC members have indicated application conflicts (using review preferences of −100 or less) that aren’t yet confirmed. Confirm these conflicts', MessageSet::MARKED_NOTE);
}
// Weird URLs?
foreach (["conferenceSite", "paperSite"] as $k) {
diff --git a/src/pages/p_autoassign.php b/src/pages/p_autoassign.php
index f9221cdcd..2814ff417 100644
--- a/src/pages/p_autoassign.php
+++ b/src/pages/p_autoassign.php
@@ -200,9 +200,9 @@ private function print_review_actions() {
["size" => 3, "class" => $this->ms->control_class("review:count", "js-autosubmit")]),
" additional ",
Ht::select("review:rtype", ["primary" => "primary", "secondary" => "secondary", "optional" => "optional", "metareview" => "metareview"], $qreq["review:type"]),
- " review(s) per selected paper\n";
+ " review(s) per selected application\n";
- $this->print_radio_row("a", "review_ensure", "Ensure each selected paper has at least", ["open" => true]);
+ $this->print_radio_row("a", "review_ensure", "Ensure each selected application has at least", ["open" => true]);
echo " ",
Ht::entry("review_ensure:count", $qreq["review_ensure:count"] ?? 1,
["size" => 3, "class" => $this->ms->control_class("review_ensure:count", "js-autosubmit")]), " ",
@@ -215,7 +215,7 @@ private function print_review_actions() {
["size" => 3, "class" => $this->ms->control_class("review_per_pc:count", "js-autosubmit")]),
" additional ",
Ht::select("review_per_pc:rtype", ["primary" => "primary", "secondary" => "secondary", "optional" => "optional", "metareview" => "metareview"], $qreq["review_per_pc:rtype"]),
- " review(s) from this paper selection";
+ " review(s) from this application selection";
// Review round
$rev_rounds = $this->conf->round_selector_options(null);
@@ -243,7 +243,7 @@ private function print_conflict_actions() {
$this->print_radio_row("a", "prefconflict", "Assign conflicts when PC members have review preferences of −100 or less");
$this->print_radio_row("a", "clear", "Clear all ", ["open" => true]);
echo Ht::select("clear:type", ["primary" => "primary", "secondary" => "secondary", "optional" => "optional", "metareview" => "metareview", "conflict" => "conflict", "lead" => "discussion lead", "shepherd" => "shepherd"], $this->qreq["clear:type"]),
- " assignments for selected papers and PC members\n";
+ " assignments for selected applications and PC members\n";
}
private function print_lead_actions() {
@@ -261,7 +261,7 @@ private function print_discussion_actions() {
$this->print_radio_row("a", "discussion_order", "Create discussion order in tag #", ["open" => true]);
echo Ht::entry("discussion_order:tag", $this->qreq["discussion_order:tag"] ?? "discuss",
["size" => 12, "class" => $this->ms->control_class("discussion_order:tag", "js-autosubmit")]),
- ", grouping papers with similar PC conflicts";
+ ", grouping applications with similar PC conflicts";
}
private function bp_selector($i, $which) {
@@ -284,7 +284,7 @@ private function print_bad_pairs() {
echo '
', $this->bp_selector($i, "a"),
" and ", $this->bp_selector($i, "b");
if ($i == 1) {
- echo ' to the same paper ( · )';
+ echo ' to the same application ( · )';
}
echo "
@@ -348,7 +348,7 @@ private function print() {
// paper selection
echo '
',
- '
Paper selection
',
+ '
Application selection
',
Ht::entry("q", $qreq->q, [
"id" => "autoassignq", "placeholder" => "(All)",
"size" => 40, "aria-label" => "Search",
@@ -363,7 +363,7 @@ private function print() {
$plist = new PaperList("reviewersSel", $search);
$plist->set_selection($this->ssel)->set_table_decor(PaperList::DECOR_HEADER);
if ($search->paper_ids()) {
- echo " Assignments will apply to the selected papers.";
+ echo " Assignments will apply to the selected applications.";
}
echo '';
$plist->print_table_html();
diff --git a/src/pages/p_bulkassign.php b/src/pages/p_bulkassign.php
index 769071334..153d55120 100644
--- a/src/pages/p_bulkassign.php
+++ b/src/pages/p_bulkassign.php
@@ -158,11 +158,11 @@ function print_instructions() {
BulkAssign_HelpTopic::print_actions($this->user);
- echo "
For example, this file clears existing R1 review assignments for papers
+ echo "
For example, this file clears existing R1 review assignments for applications
tagged #redo, then assigns two primary reviews for submission #1 and one
secondary review for submission #2:
', "\n";
diff --git a/src/pages/p_paper.php b/src/pages/p_paper.php
index 6b25ae07b..5dd05c835 100644
--- a/src/pages/p_paper.php
+++ b/src/pages/p_paper.php
@@ -84,7 +84,7 @@ function handle_withdraw() {
$aset = new AssignmentSet($this->user);
$aset->override_conflicts();
$aset->enable_papers($this->prow);
- $aset->parse("paper,action,withdraw reason\n{$this->prow->paperId},withdraw," . CsvGenerator::quote($reason));
+ $aset->parse("application,action,withdraw reason\n{$this->prow->paperId},withdraw," . CsvGenerator::quote($reason));
if (!$aset->execute()) {
error_log("{$this->conf->dbname}: withdraw #{$this->prow->paperId} failure: " . json_encode($aset->json_result()));
}
@@ -100,7 +100,7 @@ function handle_revive() {
$aset = new AssignmentSet($this->user);
$aset->override_conflicts();
$aset->enable_papers($this->prow);
- $aset->parse("paper,action\n{$this->prow->paperId},revive");
+ $aset->parse("application,action\n{$this->prow->paperId},revive");
if (!$aset->execute()) {
error_log("{$this->conf->dbname}: revive #{$this->prow->paperId} failure: " . json_encode($aset->json_result()));
}
diff --git a/src/pages/p_profile.php b/src/pages/p_profile.php
index 784e97c6b..7ed98f9d5 100644
--- a/src/pages/p_profile.php
+++ b/src/pages/p_profile.php
@@ -460,7 +460,7 @@ private function handle_delete() {
&& !empty($tracks->soleAuthor)) {
$this->conf->feedback_msg([
MessageItem::error("<5>This account can’t be deleted because it is sole contact for " . UserStatus::render_paper_link($this->conf, $tracks->soleAuthor)),
- MessageItem::inform("<0>You will be able to delete the account after deleting those papers or adding additional paper contacts.")
+ MessageItem::inform("<0>You will be able to delete the account after deleting those applications or adding additional application contacts.")
]);
} else {
$this->conf->q("insert into DeletedContactInfo set contactId=?, firstName=?, lastName=?, unaccentedName=?, email=?, affiliation=?", $this->user->contactId, $this->user->firstName, $this->user->lastName, $this->user->unaccentedName, $this->user->email, $this->user->affiliation);
@@ -472,7 +472,7 @@ private function handle_delete() {
// delete twiddle tags
$assigner = new AssignmentSet($this->viewer);
$assigner->override_conflicts();
- $assigner->parse("paper,tag\nall,{$this->user->contactId}~all#clear\n");
+ $assigner->parse("application,tag\nall,{$this->user->contactId}~all#clear\n");
$assigner->execute();
// clear caches
if ($this->user->isPC || $this->user->privChair) {
diff --git a/src/pages/p_signin.php b/src/pages/p_signin.php
index e9ad92a95..1250caa34 100644
--- a/src/pages/p_signin.php
+++ b/src/pages/p_signin.php
@@ -197,7 +197,7 @@ static function print_signin_form_description(Contact $user, Qrequest $qreq) {
}
echo '
', $user->conf->_("You are already signed in as %s. Use this form to add another account to this browser session.", commajoin($links)), '
';
}
- if (($t = $user->conf->_("Sign in to submit or review papers.")) !== "") {
+ if (($t = $user->conf->_("Sign in to submit or review applications.")) !== "") {
echo '
\n";
}
@@ -2949,7 +2949,7 @@ private function _mark_review_messages($editable, ReviewInfo $rrow) {
}
if ($ndelegated == 0) {
- $t = "As a secondary reviewer, you can conf->hoturl("assign", "p=$rrow->paperId") . "\">delegate this review to an external reviewer, but if your external reviewer declines to review the paper, you should complete this review yourself.";
+ $t = "As a secondary reviewer, you can conf->hoturl("assign", "p=$rrow->paperId") . "\">delegate this review to an external reviewer, but if your external reviewer declines to review the application, you should complete this review yourself.";
} else if ($rrow->reviewNeedsSubmit == 0) {
$t = "A delegated external reviewer has submitted their review, but you can still complete your own if you’d like.";
} else if ($napproval) {
diff --git a/src/settings/s_banal.php b/src/settings/s_banal.php
index 50378710e..0acca8443 100644
--- a/src/settings/s_banal.php
+++ b/src/settings/s_banal.php
@@ -46,7 +46,7 @@ static function print($id, $sv) {
Ht::hidden("format/{$ctr}/id", $id);
$sv->print_checkbox("format/{$ctr}/active", "PDF format checker:", ["class" => "uich js-foldup", "group_class" => "form-g has-fold " . ($open ? "foldo" : "foldc"), "group_open" => true]);
echo '
");
+ $sv->warning_at(null, "<5>Running the automated application checker on a sample PDF file produced unexpected results. You should disable it for now.
diff --git a/test/db.json b/test/db.json
index b49d140c4..ec83c2afe 100644
--- a/test/db.json
+++ b/test/db.json
@@ -54,7 +54,7 @@
{
"_id_": 3,
"title": "A Simulation Study of IP Switching",
- "abstract": "Recently there has been much interest in combining the speed of layer-2 switching with the features of layer-3 routing. This has been prompted by numerous proposals, including: IP Switching [1], Tag Switching [2], ARIS [3], CSR [4], and IP over ATM [5]. In this paper, we study IP Switching and evaluate the performance claims made by Newman et al in [1] and [6]. In particular, using ten network traces, we study how well IP Switching performs with traffic found in campus, corporate, and Internet Service Provider (ISP) environments. Our main finding is that IP Switching will lead to a high proportion of datagrams that are switched; over 75% in all of the environments we studied. We also investigate the effects that different flow classifiers and various timer values have on performance, and note that some choices can result in a large VC space requirement. Finally, we present recommendations for the flow classifier and timer values, as a function of the VC space of the switch and the network environment being served.",
+ "abstract": "Recently there has been much interest in combining the speed of layer-2 switching with the features of layer-3 routing. This has been prompted by numerous proposals, including: IP Switching [1], Tag Switching [2], ARIS [3], CSR [4], and IP over ATM [5]. In this application, we study IP Switching and evaluate the performance claims made by Newman et al in [1] and [6]. In particular, using ten network traces, we study how well IP Switching performs with traffic found in campus, corporate, and Internet Service Provider (ISP) environments. Our main finding is that IP Switching will lead to a high proportion of datagrams that are switched; over 75% in all of the environments we studied. We also investigate the effects that different flow classifiers and various timer values have on performance, and note that some choices can result in a large VC space requirement. Finally, we present recommendations for the flow classifier and timer values, as a function of the VC space of the switch and the network environment being served.",
"authors": [
{"name":"Steven Lin", "email": "sclin@leland.stanford.edu", "affiliation": "Stanford University", "contact": true},
{"name":"Nick McKeown", "email": "nickm@ee.stanford.edu", "affiliation": "Stanford University"}
@@ -67,7 +67,7 @@
{
"_id_": 4,
"title": "Scalable High Speed IP Routing Lookups",
- "abstract": "Internet address lookup is a challenging problem because of increasing routing table sizes, increased traffic, higher speed links, and the migration to 128 bit IPv6 addresses. IP routing lookup requires computing the best matching prefix, for which standard solutions like hashing were believed to be inapplicable. The best existing solution we know of, BSD radix tries, scales badly as IP moves to 128 bit addresses. Our paper describes a new algorithm for best matching prefix using binary search on hash tables organized by prefix lengths. Our scheme scales very well as address and routing table sizes increase: independent of the table size, it requires a worst case time of log2(address bits) hash lookups. Thus only 5 hash lookups are needed for IPv4 and 7 for IPv6. We also introduce Mutating Binary Search and other optimizations that, for a typical IPv4 backbone router with over 33,000 entries, considerably reduce the average number of hashes to less than 2, of which one hash can be simplified to an indexed array access. We expect similar average case behavior for IPv6.",
+ "abstract": "Internet address lookup is a challenging problem because of increasing routing table sizes, increased traffic, higher speed links, and the migration to 128 bit IPv6 addresses. IP routing lookup requires computing the best matching prefix, for which standard solutions like hashing were believed to be inapplicable. The best existing solution we know of, BSD radix tries, scales badly as IP moves to 128 bit addresses. Our application describes a new algorithm for best matching prefix using binary search on hash tables organized by prefix lengths. Our scheme scales very well as address and routing table sizes increase: independent of the table size, it requires a worst case time of log2(address bits) hash lookups. Thus only 5 hash lookups are needed for IPv4 and 7 for IPv6. We also introduce Mutating Binary Search and other optimizations that, for a typical IPv4 backbone router with over 33,000 entries, considerably reduce the average number of hashes to less than 2, of which one hash can be simplified to an indexed array access. We expect similar average case behavior for IPv6.",
"authors": [
{"name":"Marcel Waldvogel", "email": "waldvogel@tik.ee.ethz.ch", "affiliation": "Computer Engineering and Networks Laboratory, ETH Zürich", "contact": true},
{"name":"George Varghese", "email": "varghese@ccrc.wustl.edu", "affiliation": "Computer and Communications Research Center, Washington University in St. Louis", "contact": true},
@@ -93,7 +93,7 @@
{
"_id_": 6,
"title": "Trace-Based Mobile Network Emulation",
- "abstract": "Subjecting a mobile computing system to wireless network conditions that are realistic yet reproducible is a challenging problem. In this paper, we describe a technique called trace modulation that re-creates the observed end-to-end characteristics of a real wireless network in a controlled and repeatable manner. Trace modulation is transparent to applications and accounts for all network traffic sent or received by the system under test. We present results that show that it is indeed capable of reproducing wireless network performance faithfully.",
+ "abstract": "Subjecting a mobile computing system to wireless network conditions that are realistic yet reproducible is a challenging problem. In this application, we describe a technique called trace modulation that re-creates the observed end-to-end characteristics of a real wireless network in a controlled and repeatable manner. Trace modulation is transparent to applications and accounts for all network traffic sent or received by the system under test. We present results that show that it is indeed capable of reproducing wireless network performance faithfully.",
"authors": [
{"name":"Brian Noble", "email": "bnoble@cs.cmu.edu", "affiliation": "Carnegie Mellon University, School of Computer Science", "contact": true},
{"name":"M. Satyanarayanan", "email": "satya@cs.cmu.edu", "affiliation": "Carnegie Mellon University, School of Computer Science"},
@@ -106,7 +106,7 @@
{
"_id_": 7,
"title": "Fair Scheduling in Wireless Packet Networks",
- "abstract": "Fair scheduling of delay and rate-sensitive packet flows over a wireless channel is not addressed effectively by most contemporary wireline fair scheduling algorithms because of two unique characteristics of wireless media: (a) bursty channel errors, and (b) location-dependent channel capacity and errors. Besides, in packet cellular networks, the base station typically performs the task of packet scheduling for both downlink and uplink flows in a cell; however a base station has only a limited knowledge of the arrival processes of uplink flows.\n\nIn this paper, we propose a new model for wireless fair scheduling based on an adaptation of fluid fair queueing to handle location-dependent error bursts. We describe an ideal wireless fair scheduling algorithm which provides a packetized implementation of the fluid model while assuming full knowledge of the current channel conditions. For this algorithm, we derive the worst-case throughput and delay bounds. Finally, we describe a practical wireless scheduling algorithm which approximates the ideal algorithm. Through simulations, we show that the algorithm achieves the desirable properties identified in the wireless fluid fair queueing model.",
+ "abstract": "Fair scheduling of delay and rate-sensitive packet flows over a wireless channel is not addressed effectively by most contemporary wireline fair scheduling algorithms because of two unique characteristics of wireless media: (a) bursty channel errors, and (b) location-dependent channel capacity and errors. Besides, in packet cellular networks, the base station typically performs the task of packet scheduling for both downlink and uplink flows in a cell; however a base station has only a limited knowledge of the arrival processes of uplink flows.\n\nIn this application, we propose a new model for wireless fair scheduling based on an adaptation of fluid fair queueing to handle location-dependent error bursts. We describe an ideal wireless fair scheduling algorithm which provides a packetized implementation of the fluid model while assuming full knowledge of the current channel conditions. For this algorithm, we derive the worst-case throughput and delay bounds. Finally, we describe a practical wireless scheduling algorithm which approximates the ideal algorithm. Through simulations, we show that the algorithm achieves the desirable properties identified in the wireless fluid fair queueing model.",
"authors": [
{"name":"Songwu Lu", "email": "slu@crhc.uiuc.edu", "affiliation": "UIUC", "contact": true},
{"name":"Vaduvur Bharghavan", "email": "bharghav@crhc.uiuc.edu", "affiliation": "UIUC"},
@@ -118,7 +118,7 @@
{
"_id_": 8,
"title": "Fast Restoration of Real-Time Communication Service from Component Failures in Multi-Hop Networks",
- "abstract": "For many applications it is important to provide communication services with guaranteed timeliness and fault-tolerance at an acceptable level of overhead. In this paper, we present a scheme for restoring real-time channels, each with guaranteed timeliness, from component failures in multi-hop networks. To ensure fast/guaranteed recovery, backup channels are set up a priori in addition to each primary channel. That is, a dependable real-time connection consists of a primary channel and one or more backup channels. If a primary channel fails, one of its backup channels is activated to become a new primary channel. We describe a protocol which provides an integrated solution to the failure-recovery problem (i.e., channel switching, resource re-allocation, ...). We also present a resource sharing method that significantly reduces the overhead of backup channels. The simulation results show that good coverage (in recovering from failures) can be achieved with about 30% degradation in network utilization under a reasonable failure condition. Moreover, the fault-tolerance level of each dependable connection can be controlled, independently of other connections, to reflect its criticality.",
+ "abstract": "For many applications it is important to provide communication services with guaranteed timeliness and fault-tolerance at an acceptable level of overhead. In this application, we present a scheme for restoring real-time channels, each with guaranteed timeliness, from component failures in multi-hop networks. To ensure fast/guaranteed recovery, backup channels are set up a priori in addition to each primary channel. That is, a dependable real-time connection consists of a primary channel and one or more backup channels. If a primary channel fails, one of its backup channels is activated to become a new primary channel. We describe a protocol which provides an integrated solution to the failure-recovery problem (i.e., channel switching, resource re-allocation, ...). We also present a resource sharing method that significantly reduces the overhead of backup channels. The simulation results show that good coverage (in recovering from failures) can be achieved with about 30% degradation in network utilization under a reasonable failure condition. Moreover, the fault-tolerance level of each dependable connection can be controlled, independently of other connections, to reflect its criticality.",
"authors": [
{"name":"Seungjae Han", "email": "sjhan@eecs.umich.edu", "affiliation": "University of Michigan", "contact": true},
{"name":"Kang G. Shin", "email": "kgshin@eecs.umich.edu", "affiliation": "University of Michigan"}
@@ -140,7 +140,7 @@
{
"_id_": 10,
"title": "Active Bridging",
- "abstract": "Active networks accelerate network evolution by permitting the network infrastructure to be programmable, on a per-user, per-packet, or other basis. This programmability must be balanced against the safety and security needs inherent in shared resources.This paper describes the design, implementation, and performance of a new type of network element, an Active Bridge. The active bridge can be reprogrammed \"on the fly\", with loadable modules called switchlets. To demonstrate the use of the active property, we incrementally extend what is initially a programmable buffered repeater with switchlets into a self-learning bridge, and then a bridge supporting spanning tree algorithms. To demonstrate the agility that active networking gives, we show how it is possible to upgrade a network from an \"old\" protocol to a \"new\" protocol on-the-fly. Moreover, we are able to take advantage of information unavailable to the implementors of either protocol to validate the new protocol and fall back to the old protocol if an error is detected. This shows that the Active Bridge can protect itself from some algorithmic failures in loadable modules.Our approach to safety and security favors static checking and prevention over dynamic checks when possible. We rely on strong type checking in the Caml language for the loadable module infrastructure, and achieve respectable performance. The prototype implementation on a Pentium-based HP Netserver LS running Linux with 100 Mbps Ethernet LANS achieves ttcp throughput of 16 Mbps between two PCs running Linux, compared with 76 Mbps unbridged. Measured frame rates are in the neighborhood of 1800 frames per second.",
+ "abstract": "Active networks accelerate network evolution by permitting the network infrastructure to be programmable, on a per-user, per-packet, or other basis. This programmability must be balanced against the safety and security needs inherent in shared resources.This application describes the design, implementation, and performance of a new type of network element, an Active Bridge. The active bridge can be reprogrammed \"on the fly\", with loadable modules called switchlets. To demonstrate the use of the active property, we incrementally extend what is initially a programmable buffered repeater with switchlets into a self-learning bridge, and then a bridge supporting spanning tree algorithms. To demonstrate the agility that active networking gives, we show how it is possible to upgrade a network from an \"old\" protocol to a \"new\" protocol on-the-fly. Moreover, we are able to take advantage of information unavailable to the implementors of either protocol to validate the new protocol and fall back to the old protocol if an error is detected. This shows that the Active Bridge can protect itself from some algorithmic failures in loadable modules.Our approach to safety and security favors static checking and prevention over dynamic checks when possible. We rely on strong type checking in the Caml language for the loadable module infrastructure, and achieve respectable performance. The prototype implementation on a Pentium-based HP Netserver LS running Linux with 100 Mbps Ethernet LANS achieves ttcp throughput of 16 Mbps between two PCs running Linux, compared with 76 Mbps unbridged. Measured frame rates are in the neighborhood of 1800 frames per second.",
"authors": [
{"name":"D. Scott Alexander", "email": "salex@dsl.cis.upenn.edu", "affiliation": "University of Pennsylvania", "contact": true},
{"name":"Marianne Shaw", "email": "marianne@dsl.cis.upenn.edu", "affiliation": "University of Pennsylvania"},
@@ -153,7 +153,7 @@
{
"_id_": 11,
"title": "Internet Routing Instability",
- "abstract": "This paper examines the network inter-domain routing information exchanged between backbone service providers at the major U.S. public Internet exchange points. Internet routing instability, or the rapid fluctuation of network reachability information, is an important problem currently facing the Internet engineering community. High levels of network instability can lead to packet loss, increased network latency and time to convergence. At the extreme, high levels of routing instability have lead to the loss of internal connectivity in wide-area, national networks. In this paper, we describe several unexpected trends in routing instability, and examine a number of anomalies and pathologies observed in the exchange of inter-domain routing information. The analysis in this paper is based on data collected from BGP routing messages generated by border routers at five of the Internet core's public exchange points during a nine month period. We show that the volume of these routing updates is several orders of magnitude more than expected and that the majority of this routing information is redundant, or pathological. Furthermore, our analysis reveals several unexpected trends and ill-behaved systematic properties in Internet routing. We finally posit a number of explanations for these anomalies and evaluate their potential impact on the Internet infrastructure.",
+ "abstract": "This application examines the network inter-domain routing information exchanged between backbone service providers at the major U.S. public Internet exchange points. Internet routing instability, or the rapid fluctuation of network reachability information, is an important problem currently facing the Internet engineering community. High levels of network instability can lead to packet loss, increased network latency and time to convergence. At the extreme, high levels of routing instability have lead to the loss of internal connectivity in wide-area, national networks. In this application, we describe several unexpected trends in routing instability, and examine a number of anomalies and pathologies observed in the exchange of inter-domain routing information. The analysis in this application is based on data collected from BGP routing messages generated by border routers at five of the Internet core's public exchange points during a nine month period. We show that the volume of these routing updates is several orders of magnitude more than expected and that the majority of this routing information is redundant, or pathological. Furthermore, our analysis reveals several unexpected trends and ill-behaved systematic properties in Internet routing. We finally posit a number of explanations for these anomalies and evaluate their potential impact on the Internet infrastructure.",
"authors": [
{"name":"Craig Labovitz", "email": "labovit@eecs.umich.edu", "affiliation": "University of Michigan Department of Electrical Engineering and Computer Science", "contact": true},
{"name":"G. Robert Malan", "email": "rmalan@eecs.umich.edu", "affiliation": "University of Michigan Department of Electrical Engineering and Computer Science", "contact": true},
@@ -165,7 +165,7 @@
{
"_id_": 12,
"title": "Dynamics of Random Early Detection",
- "abstract": "In this paper we evaluate the effectiveness of Random Early Detection (RED) over traffic types categorized as non-adaptive, fragile and robust, according to their responses to congestion. We point out that RED allows unfair bandwidth sharing when a mixture of the three traffic types shares a link. This unfairness is caused by the fact that at any given time RED imposes the same loss rate on all flows, regardless of their bandwidths.\n\nWe propose Fair Random Early Drop (FRED), a modified version of RED. FRED uses per-active-flow accounting to impose on each flow a loss rate that depends on the flow's buffer use.\n\nWe show that FRED provides better protection than RED for adaptive (fragile and robust) flows. In addition, FRED is able to isolate non-adaptive greedy traffic more effectively. Finally, we present a \"two-packet-buffer\" gateway mechanism to support a large number of flows without incurring additional queueing delays inside the network. These improvements are demonstrated by simulations of TCP and UDP traffic.\n\nFRED does not make any assumptions about queueing architecture; it will work with a FIFO gateway. FRED's per-active-flow accounting uses memory in proportion to the total number of buffers used: a FRED gateway maintains state only for flows for which it has packets buffered, not for all flows that traverse the gateway.",
+ "abstract": "In this application we evaluate the effectiveness of Random Early Detection (RED) over traffic types categorized as non-adaptive, fragile and robust, according to their responses to congestion. We point out that RED allows unfair bandwidth sharing when a mixture of the three traffic types shares a link. This unfairness is caused by the fact that at any given time RED imposes the same loss rate on all flows, regardless of their bandwidths.\n\nWe propose Fair Random Early Drop (FRED), a modified version of RED. FRED uses per-active-flow accounting to impose on each flow a loss rate that depends on the flow's buffer use.\n\nWe show that FRED provides better protection than RED for adaptive (fragile and robust) flows. In addition, FRED is able to isolate non-adaptive greedy traffic more effectively. Finally, we present a \"two-packet-buffer\" gateway mechanism to support a large number of flows without incurring additional queueing delays inside the network. These improvements are demonstrated by simulations of TCP and UDP traffic.\n\nFRED does not make any assumptions about queueing architecture; it will work with a FIFO gateway. FRED's per-active-flow accounting uses memory in proportion to the total number of buffers used: a FRED gateway maintains state only for flows for which it has packets buffered, not for all flows that traverse the gateway.",
"authors": [
{"name":"Dong Lin", "affiliation": "Harvard University"},
{"name":"Robert Morris", "email": "rtm@eecs.harvard.edu", "affiliation": "Harvard University", "contact": true}
@@ -187,7 +187,7 @@
{
"_id_": 14,
"title": "Network Performance Effects of HTTP/1.1, CSS1, and PNG",
- "abstract": "We describe our investigation of the effect of persistent connections, pipelining and link level document compression on our client and server HTTP implementations. A simple test setup is used to verify HTTP/1.1's design and understand HTTP/1.1 implementation strategies. We present TCP and real time performance data between the libwww robot [27] and both the W3C's Jigsaw [28] and Apache [29] HTTP servers using HTTP/1.0, HTTP/1.1 with persistent connections, HTTP/1.1 with pipelined requests, and HTTP/1.1 with pipelined requests and deflate data compression [22]. We also investigate whether the TCP Nagle algorithm has an effect on HTTP/1.1 performance. While somewhat artificial and possibly overstating the benefits of HTTP/1.1, we believe the tests and results approximate some common behavior seen in browsers. The results confirm that HTTP/1.1 is meeting its major design goals. Our experience has been that implementation details are very important to achieve all of the benefits of HTTP/1.1.\n\nFor all our tests, a pipelined HTTP/1.1 implementation outperformed HTTP/1.0, even when the HTTP/1.0 implementation used multiple connections in parallel, under all network environments tested. The savings were at least a factor of two, and sometimes as much as a factor of ten, in terms of packets transmitted. Elapsed time improvement is less dramatic, and strongly depends on your network connection.Some data is presented showing further savings possible by changes in Web content, specifically by the use of CSS style sheets [10], and the more compact PNG [20] image representation, both recent recommendations of W3C. Time did not allow full end to end data collection on these cases. The results show that HTTP/1.1 and changes in Web content will have dramatic results in Internet and Web performance as HTTP/1.1 and related technologies deploy over the near future. Universal use of style sheets, even without deployment of HTTP/1.1, would cause a very significant reduction in network traffic.This paper does not investigate further performance and network savings enabled by the improved caching facilities provided by the HTTP/1.1 protocol, or by sophisticated use of range requests.",
+ "abstract": "We describe our investigation of the effect of persistent connections, pipelining and link level document compression on our client and server HTTP implementations. A simple test setup is used to verify HTTP/1.1's design and understand HTTP/1.1 implementation strategies. We present TCP and real time performance data between the libwww robot [27] and both the W3C's Jigsaw [28] and Apache [29] HTTP servers using HTTP/1.0, HTTP/1.1 with persistent connections, HTTP/1.1 with pipelined requests, and HTTP/1.1 with pipelined requests and deflate data compression [22]. We also investigate whether the TCP Nagle algorithm has an effect on HTTP/1.1 performance. While somewhat artificial and possibly overstating the benefits of HTTP/1.1, we believe the tests and results approximate some common behavior seen in browsers. The results confirm that HTTP/1.1 is meeting its major design goals. Our experience has been that implementation details are very important to achieve all of the benefits of HTTP/1.1.\n\nFor all our tests, a pipelined HTTP/1.1 implementation outperformed HTTP/1.0, even when the HTTP/1.0 implementation used multiple connections in parallel, under all network environments tested. The savings were at least a factor of two, and sometimes as much as a factor of ten, in terms of packets transmitted. Elapsed time improvement is less dramatic, and strongly depends on your network connection.Some data is presented showing further savings possible by changes in Web content, specifically by the use of CSS style sheets [10], and the more compact PNG [20] image representation, both recent recommendations of W3C. Time did not allow full end to end data collection on these cases. The results show that HTTP/1.1 and changes in Web content will have dramatic results in Internet and Web performance as HTTP/1.1 and related technologies deploy over the near future. Universal use of style sheets, even without deployment of HTTP/1.1, would cause a very significant reduction in network traffic.This application does not investigate further performance and network savings enabled by the improved caching facilities provided by the HTTP/1.1 protocol, or by sophisticated use of range requests.",
"authors": [
{"name":"Henrik Frystyk Nielsen", "email": "frystyk@w3.org", "affiliation": "World Wide Web Consortium", "contact": true},
{"name":"James Gettys", "email": "jg@pa.dec.com", "affiliation": "Visiting Scientist, World Wide Web Consortium; Digital Equipment Corporation", "contact": true},
@@ -212,7 +212,7 @@
{
"_id_": 16,
"title": "Potential Benefits of Delta Encoding and Data Compression for HTTP",
- "abstract": "Caching in the World Wide Web currently follows a naive model, which assumes that resources are referenced many times between changes. The model also provides no way to update a cache entry if a resource does change, except by transferring the resource's entire new value. Several previous papers have proposed updating cache entries by transferring only the differences, or \"delta,\" between the cached entry and the current value.\n\nIn this paper, we make use of dynamic traces of the full contents of HTTP messages to quantify the potential benefits of delta-encoded responses. We show that delta encoding can provide remarkable improvements in response size and response delay for an important subset of HTTP content types. We also show the added benefit of data compression, and that the combination of delta encoding and data compression yields the best results.\n\nWe propose specific extensions to the HTTP protocol for delta encoding and data compression. These extensions are compatible with existing implementations and specifications, yet allow efficient use of a variety of encoding techniques.",
+ "abstract": "Caching in the World Wide Web currently follows a naive model, which assumes that resources are referenced many times between changes. The model also provides no way to update a cache entry if a resource does change, except by transferring the resource's entire new value. Several previous applications have proposed updating cache entries by transferring only the differences, or \"delta,\" between the cached entry and the current value.\n\nIn this application, we make use of dynamic traces of the full contents of HTTP messages to quantify the potential benefits of delta-encoded responses. We show that delta encoding can provide remarkable improvements in response size and response delay for an important subset of HTTP content types. We also show the added benefit of data compression, and that the combination of delta encoding and data compression yields the best results.\n\nWe propose specific extensions to the HTTP protocol for delta encoding and data compression. These extensions are compatible with existing implementations and specifications, yet allow efficient use of a variety of encoding techniques.",
"authors": [
{"name":"Jeffrey C. Mogul", "email": "mogul@wrl.dec.com", "affiliation": "Digital Equipment Corporation Western Research Laboratory", "contact": true},
{"name":"Fred Douglis", "email": "douglis@research.att.com", "affiliation": "AT&T Labs - Research"},
@@ -225,7 +225,7 @@
{
"_id_": 17,
"title": "Network Text Editor (NTE): A Scalable Shared Text Editor for the MBone",
- "abstract": "IP Multicast, Lightweight Sessions and Application Level Framing provide guidelines by which multimedia conferencing tools can be designed, but they do not provide specific solutions. In this paper, we use these design principles to guide the design of a multicast based shared editor, and examine the consequences of taking a loose consistency approach to achieve good performance in the face of network failures and losses.",
+ "abstract": "IP Multicast, Lightweight Sessions and Application Level Framing provide guidelines by which multimedia conferencing tools can be designed, but they do not provide specific solutions. In this application, we use these design principles to guide the design of a multicast based shared editor, and examine the consequences of taking a loose consistency approach to achieve good performance in the face of network failures and losses.",
"authors": [
{"name":"Mark Handley", "email": "mjh@isi.edu", "affiliation": "USC Information Sciences Institute", "contact": true},
{"name":"Jon Crowcroft", "email": "jon@cs.ucl.ac.uk", "affiliation": "University College London", "contact": true}
@@ -236,7 +236,7 @@
{
"_id_": 18,
"title": "Consistent Overhead Byte Stuffing",
- "abstract": "Byte stuffing is a process that transforms a sequence of data bytes that may contain 'illegal' or 'reserved' values into a potentially longer sequence that contains no occurrences of those values. The extra length is referred to in this paper as the overhead of the algorithm.\n\nTo date, byte stuffing algorithms, such as those used by SLIP [RFC1055], PPP [RFC1662] and AX.25 [ARRL84], have been designed to incur low average overhead but have made little effort to minimize worst case overhead.\n\nSome increasingly popular network devices, however, care more about the worst case. For example, the transmission time for ISM-band packet radio transmitters is strictly limited by FCC regulation. To adhere to this regulation, the practice is to set the maximum packet size artificially low so that no packet, even after worst case overhead, can exceed the transmission time limit.\n\nThis paper presents a new byte stuffing algorithm, called Consistent Overhead Byte Stuffing (COBS), that tightly bounds the worst case overhead. It guarantees in the worst case to add no more than one byte in 254 to any packet. Furthermore, the algorithm is computationally cheap, and its average overhead is very competitive with that of existing algorithms.",
+ "abstract": "Byte stuffing is a process that transforms a sequence of data bytes that may contain 'illegal' or 'reserved' values into a potentially longer sequence that contains no occurrences of those values. The extra length is referred to in this application as the overhead of the algorithm.\n\nTo date, byte stuffing algorithms, such as those used by SLIP [RFC1055], PPP [RFC1662] and AX.25 [ARRL84], have been designed to incur low average overhead but have made little effort to minimize worst case overhead.\n\nSome increasingly popular network devices, however, care more about the worst case. For example, the transmission time for ISM-band packet radio transmitters is strictly limited by FCC regulation. To adhere to this regulation, the practice is to set the maximum packet size artificially low so that no packet, even after worst case overhead, can exceed the transmission time limit.\n\nThis application presents a new byte stuffing algorithm, called Consistent Overhead Byte Stuffing (COBS), that tightly bounds the worst case overhead. It guarantees in the worst case to add no more than one byte in 254 to any packet. Furthermore, the algorithm is computationally cheap, and its average overhead is very competitive with that of existing algorithms.",
"authors": [
{"name":"Stuart Cheshire", "email": "cheshire@cs.stanford.edu", "affiliation": "Computer Science Department, Stanford University", "contact": true},
{"name":"Mary Baker", "email": "mgbaker@cs.stanford.edu", "affiliation": "Computer Science Department, Stanford University"}
@@ -247,7 +247,7 @@
{
"_id_": 19,
"title": "A Flow-Based Approach to Datagram Security",
- "abstract": "Datagram services provide a simple, flexible, robust, and scalable communication abstraction; their usefulness has been well demonstrated by the success of IP, UDP, and RPC. Yet, the overwhelming majority of network security protocols that have been proposed are geared towards connection-oriented communications. The few that do cater to datagram communications tend to either rely on long term host-pair keying or impose a session-oriented (i.e., requiring connection setup) semantics.\n\nSeparately, the concept of flows has received a great deal of attention recently, especially in the context of routing and QoS. A flow characterizes a sequence of datagrams sharing some pre-defined attributes. In this paper, we advocate the use of flows as a basis for structuring secure datagram communications. We support this by proposing a novel protocol for datagram security based on flows. Our protocol achieves zero-message keying, thus preserving the connectionless nature of datagram, and makes use of soft state, thus providing the efficiency of session-oriented schemes. We have implemented an instantiation for IP in the 4.4BSD kernel, and we provide a description of our implementation along with performance results.",
+ "abstract": "Datagram services provide a simple, flexible, robust, and scalable communication abstraction; their usefulness has been well demonstrated by the success of IP, UDP, and RPC. Yet, the overwhelming majority of network security protocols that have been proposed are geared towards connection-oriented communications. The few that do cater to datagram communications tend to either rely on long term host-pair keying or impose a session-oriented (i.e., requiring connection setup) semantics.\n\nSeparately, the concept of flows has received a great deal of attention recently, especially in the context of routing and QoS. A flow characterizes a sequence of datagrams sharing some pre-defined attributes. In this application, we advocate the use of flows as a basis for structuring secure datagram communications. We support this by proposing a novel protocol for datagram security based on flows. Our protocol achieves zero-message keying, thus preserving the connectionless nature of datagram, and makes use of soft state, thus providing the efficiency of session-oriented schemes. We have implemented an instantiation for IP in the 4.4BSD kernel, and we provide a description of our implementation along with performance results.",
"authors": [
{"name": "Suvo Mittra", "email": "suvo@cs.stanford.edu", "affiliation": "Stanford University", "contact": true},
{"name": "Thomas Y.C. Woo", "email": "woo@research.bell-labs.com", "affiliation": "Bell Laboratories"}
@@ -258,7 +258,7 @@
{
"_id_": 20,
"title": "Best-Effort versus Reservations: A Simple Comparative Analysis",
- "abstract": "Using a simple analytical model, this paper addresses the following question: Should the Internet retain its best-effort-only architecture, or should it adopt one that is reservation-capable? We characterize the differences between reservation-capable and best-effort-only networks in terms of application performance and total welfare. Our analysis does not yield a definitive answer to the question we pose, since it would necessarily depend on unknowable factors such as the future cost of network bandwidth and the nature of the future traffic load. However, our model does reveal some interesting phenomena. First, in some circumstances, the amount of incremental bandwidth needed to make a best-effort-only network perform as well as a reservation capable one diverges as capacity increases. Second, in some circumstances reservation-capable networks retain significant advantages over best-effort-only networks, no matter how cheap bandwidth becomes. Lastly, we find bounds on the maximum performance advantage a reservation-capable network can achieve over best effort architectures.",
+ "abstract": "Using a simple analytical model, this application addresses the following question: Should the Internet retain its best-effort-only architecture, or should it adopt one that is reservation-capable? We characterize the differences between reservation-capable and best-effort-only networks in terms of application performance and total welfare. Our analysis does not yield a definitive answer to the question we pose, since it would necessarily depend on unknowable factors such as the future cost of network bandwidth and the nature of the future traffic load. However, our model does reveal some interesting phenomena. First, in some circumstances, the amount of incremental bandwidth needed to make a best-effort-only network perform as well as a reservation capable one diverges as capacity increases. Second, in some circumstances reservation-capable networks retain significant advantages over best-effort-only networks, no matter how cheap bandwidth becomes. Lastly, we find bounds on the maximum performance advantage a reservation-capable network can achieve over best effort architectures.",
"authors": [
{"name": "Lee Breslau", "email": "breslau@parc.xerox.com", "affiliation": "Xerox Palo Alto Research Center", "contact": true},
{"name": "Scott Shenker", "email": "shenker@parc.xerox.com", "affiliation": "Xerox Palo Alto Research Center"}
@@ -269,7 +269,7 @@
{
"_id_": 21,
"title": "Quality of Service Based Routing: A Performance Perspective",
- "abstract": "Recent studies provide evidence that Quality of Service (QoS) routing can provide increased network utilization compared to routing that is not sensitive to QoS requirements of traffic. However, there are still strong concerns about the increased cost of QoS routing, both in terms of more complex and frequent computations and increased routing protocol overhead. The main goals of this paper are to study these two cost components, and propose solutions that achieve good routing performance with reduced processing cost. First, we identify the parameters that determine the protocol traffic overhead, namely (a) policy for triggering updates, (b) sensitivity of this policy, and (c) clampdown timers that limit the rate of updates. Using simulation, we study the relative significance of these factors and investigate the relationship between routing performance and the amount of update traffic. In addition, we explore a range of design options to reduce the processing cost of QoS routing algorithms, and study their effect on routing performance. Based on the conclusions of these studies, we develop extensions to the basic QoS routing, that can achieve good routing performance with limited update generation rates. The paper also addresses the impact on the results of a number of secondary factors such as topology, high level admission control, and characteristics of network traffic.",
+ "abstract": "Recent studies provide evidence that Quality of Service (QoS) routing can provide increased network utilization compared to routing that is not sensitive to QoS requirements of traffic. However, there are still strong concerns about the increased cost of QoS routing, both in terms of more complex and frequent computations and increased routing protocol overhead. The main goals of this application are to study these two cost components, and propose solutions that achieve good routing performance with reduced processing cost. First, we identify the parameters that determine the protocol traffic overhead, namely (a) policy for triggering updates, (b) sensitivity of this policy, and (c) clampdown timers that limit the rate of updates. Using simulation, we study the relative significance of these factors and investigate the relationship between routing performance and the amount of update traffic. In addition, we explore a range of design options to reduce the processing cost of QoS routing algorithms, and study their effect on routing performance. Based on the conclusions of these studies, we develop extensions to the basic QoS routing, that can achieve good routing performance with limited update generation rates. The application also addresses the impact on the results of a number of secondary factors such as topology, high level admission control, and characteristics of network traffic.",
"authors": [
{"name": "George Apostolopoulos", "affiliation": "University of Maryland"},
{"name": "Roch Guérin", "affiliation": "IBM T. J. Watson Research Center"},
@@ -282,7 +282,7 @@
{
"_id_": 22,
"title": "Scalable QoS Provision Through Buffer Management",
- "abstract": "In recent years, a number of link scheduling algorithms have been proposed that greatly improve upon traditional FIFO scheduling in being able to assure rate and delay bounds for individual sessions. However, they cannot be easily deployed in a backbone environ ment with thousands of sessions, as their complexity increases with the number of sessions. In this paper, we propose and analyze an approach that uses a simple buffer management scheme to provide rate guarantees to individual flows (or to a set of flows) multiplexed into a common FIFO queue. We establish the buffer allocation re quirements to achieve these rate guarantees and study the trade-off between the achievable link utilization and the buffer size required with the proposed scheme. The aspect of fair access to excess band width is also addressed, and its mapping onto a buffer allocation rule is investigated. Numerical examples are provided that illus trate the performance of the proposed schemes. Finally, a scalable architecture for QoS provisioning is presented that integrates the proposed buffer management scheme with WFQ scheduling that uses a small number of queues.",
+ "abstract": "In recent years, a number of link scheduling algorithms have been proposed that greatly improve upon traditional FIFO scheduling in being able to assure rate and delay bounds for individual sessions. However, they cannot be easily deployed in a backbone environ ment with thousands of sessions, as their complexity increases with the number of sessions. In this application, we propose and analyze an approach that uses a simple buffer management scheme to provide rate guarantees to individual flows (or to a set of flows) multiplexed into a common FIFO queue. We establish the buffer allocation re quirements to achieve these rate guarantees and study the trade-off between the achievable link utilization and the buffer size required with the proposed scheme. The aspect of fair access to excess band width is also addressed, and its mapping onto a buffer allocation rule is investigated. Numerical examples are provided that illus trate the performance of the proposed schemes. Finally, a scalable architecture for QoS provisioning is presented that integrates the proposed buffer management scheme with WFQ scheduling that uses a small number of queues.",
"authors": [
{"name": "R. Guérin", "email": "guerin@watson.ibm.com", "affiliation": "IBM T. J. Watson Research Center", "contact": true},
{"name": "S. Kamat", "email": "sanjay@watson.ibm.com", "affiliation": "IBM T. J. Watson Research Center", "contact": true},
@@ -295,7 +295,7 @@
{
"_id_": 23,
"title": "Data networks as cascades: Explaining the multifractal nature of Internet WAN traffic",
- "abstract": "In apparent contrast to the well-documented self-similar (i.e., monofractal) scaling behavior of measured LAN traffic, recent studies have suggested that measured TCP/IP and ATM WAN traffic exhibits more complex scaling behavior, consistent with multifractals. To bring multifractals into the realm of networking, this paper provides a simple construction based on cascades (also known as multiplicative processes) that is motivated by the protocol hierarchy of IP data networks. The cascade framework allows for a plausible physical explanation of the observed multifractal scaling behavior of data traffic and suggests that the underlying multiplicative structure is a traffic invariant for WAN traffic that co-exists with self-similarity. In particular, cascades allow us to refine the previously observed self-similar nature of data traffic to account for local irregularities in WAN traffic that are typically associated with networking mechanisms operating on small time scales, such as TCP flow control.\n\nTo validate our approach, we show that recent measurements of Internet WAN traffic from both an ISP and a corporate environment are fully consistent with the proposed cascade paradigm and hence with multifractality. We rely on wavelet-based time-scale analysis techniques to visualize and to infer the scaling behavior of the traces, both globally and locally. We also discuss and illustrate with some examples how this cascade-based approach to describing data network traffic suggests novel ways for dealing with networking problems and helps in building intuition and physical understanding about the possible implications of multifractality on issues related to network performance analysis.",
+ "abstract": "In apparent contrast to the well-documented self-similar (i.e., monofractal) scaling behavior of measured LAN traffic, recent studies have suggested that measured TCP/IP and ATM WAN traffic exhibits more complex scaling behavior, consistent with multifractals. To bring multifractals into the realm of networking, this application provides a simple construction based on cascades (also known as multiplicative processes) that is motivated by the protocol hierarchy of IP data networks. The cascade framework allows for a plausible physical explanation of the observed multifractal scaling behavior of data traffic and suggests that the underlying multiplicative structure is a traffic invariant for WAN traffic that co-exists with self-similarity. In particular, cascades allow us to refine the previously observed self-similar nature of data traffic to account for local irregularities in WAN traffic that are typically associated with networking mechanisms operating on small time scales, such as TCP flow control.\n\nTo validate our approach, we show that recent measurements of Internet WAN traffic from both an ISP and a corporate environment are fully consistent with the proposed cascade paradigm and hence with multifractality. We rely on wavelet-based time-scale analysis techniques to visualize and to infer the scaling behavior of the traces, both globally and locally. We also discuss and illustrate with some examples how this cascade-based approach to describing data network traffic suggests novel ways for dealing with networking problems and helps in building intuition and physical understanding about the possible implications of multifractality on issues related to network performance analysis.",
"authors": [
{"name": "A. Feldmann", "email": "anja@research.att.com", "affiliation": "AT&T Labs—Research", "contact": true},
{"name": "A. C. Gilbert", "email": "agilbert@research.att.com", "affiliation": "AT&T Labs—Research"},
@@ -320,7 +320,7 @@
{
"_id_": 25,
"title": "Secure Group Communications Using Key Graphs",
- "abstract": "Many emerging applications (e.g., teleconference, real-time information services, pay per view, distributed interactive simulation, and collaborative work) are based upon a group communications model, i.e., they require packet delivery from one or more authorized senders to a very large number of authorized receivers. As a result, securing group communications (i.e., providing confidentiality, integrity, and authenticity of messages delivered between group members) will become a critical networking issue. In this paper, we present a novel solution to the scalability problem of group/multicast key management. We formalize the notion of a secure group as a triple (U; K; R) where U denotes a set of users, K a set of keys held by the users, and R a user-key relation. We then introduce key graphs to specify secure groups. For a special class of key graphs, we present three strategies for securely distributing rekey messages after a join/leave, and specify protocols for joining and leaving a secure group. The rekeying strategies and join/leave protocols are implemented in a prototype group key server we have built. We present measurement results from experiments and discuss performance comparisons. We show that our group key management service, using any of the three rekeying strategies, is scalable to large groups with frequent joins and leaves. In particular, the average measured processing time per join/leave increases linearly with the logarithm of group size.",
+ "abstract": "Many emerging applications (e.g., teleconference, real-time information services, pay per view, distributed interactive simulation, and collaborative work) are based upon a group communications model, i.e., they require packet delivery from one or more authorized senders to a very large number of authorized receivers. As a result, securing group communications (i.e., providing confidentiality, integrity, and authenticity of messages delivered between group members) will become a critical networking issue. In this application, we present a novel solution to the scalability problem of group/multicast key management. We formalize the notion of a secure group as a triple (U; K; R) where U denotes a set of users, K a set of keys held by the users, and R a user-key relation. We then introduce key graphs to specify secure groups. For a special class of key graphs, we present three strategies for securely distributing rekey messages after a join/leave, and specify protocols for joining and leaving a secure group. The rekeying strategies and join/leave protocols are implemented in a prototype group key server we have built. We present measurement results from experiments and discuss performance comparisons. We show that our group key management service, using any of the three rekeying strategies, is scalable to large groups with frequent joins and leaves. In particular, the average measured processing time per join/leave increases linearly with the logarithm of group size.",
"authors": [
{"name": "Chung Kei Wong", "email": "ckwong@cs.utexas.edu", "affiliation": "Department of Computer Sciences, University of Texas at Austin", "contact": true},
{"name": "Mohamed Gouda", "email": "gouda@cs.utexas.edu", "affiliation": "Department of Computer Sciences, University of Texas at Austin"},
@@ -332,7 +332,7 @@
{
"_id_": 26,
"title": "Achieving bounded fairness for multicast and TCP traffic in the internet",
- "abstract": "There is an urgent need for effective multicast congestion control algorithms which enable reasonably fair sharing of network resources between multicast and unicast TCP traffic under the current Internet infrastructure. In this paper, we propose a quantitative definition of a type of bounded fairness between multicast and unicast best-effort traffic, termed essentially fair. We also propose a window-based Random Listening Algorithm (RLA) for multicast congestion control. The algorithm is proven to be essentially fair to TCP connections under a restricted topology with equal round-trip times and with phase effects eliminated. The algorithm is also fair to multiple multicast sessions. This paper provides the theoretical proofs and some simulation results to demonstrate that the RLA achieves good performance under various network topologies. These include the performance of a generalization of the RLA algorithm for topologies with different round-trip times.",
+ "abstract": "There is an urgent need for effective multicast congestion control algorithms which enable reasonably fair sharing of network resources between multicast and unicast TCP traffic under the current Internet infrastructure. In this application, we propose a quantitative definition of a type of bounded fairness between multicast and unicast best-effort traffic, termed essentially fair. We also propose a window-based Random Listening Algorithm (RLA) for multicast congestion control. The algorithm is proven to be essentially fair to TCP connections under a restricted topology with equal round-trip times and with phase effects eliminated. The algorithm is also fair to multiple multicast sessions. This application provides the theoretical proofs and some simulation results to demonstrate that the RLA achieves good performance under various network topologies. These include the performance of a generalization of the RLA algorithm for topologies with different round-trip times.",
"authors": [
{"name": "Huayan Amy Wang", "email": "whycu@ctr.columbia.edu", "affiliation": "Department of Electrical Engineering, Columbia University", "contact": true},
{"name": "Mischa Schwartz", "email": "schwartz@ctr.columbia.edu", "affiliation": "Department of Electrical Engineering, Columbia University"}
@@ -358,7 +358,7 @@
{
"_id_": 28,
"title": "Session Directories and Internet Multicast Address Allocation",
- "abstract": "A multicast session directory is a mechanism by which users can discover the existence of multicast sessions. In the Mbone, session announcements have also served as multicast address reservations - a dual purpose that is efficient, but which may cause some side-affects as session directories scale.\n\nIn this paper we examine the scaling of multicast address allocation when it is performed by such a multicast session directory. Despite our best efforts to make such an approach scale, this analysis ultimately reveals significant scaling problems, and suggests a new approach to multicast address allocation in the Internet environment.",
+ "abstract": "A multicast session directory is a mechanism by which users can discover the existence of multicast sessions. In the Mbone, session announcements have also served as multicast address reservations - a dual purpose that is efficient, but which may cause some side-affects as session directories scale.\n\nIn this application we examine the scaling of multicast address allocation when it is performed by such a multicast session directory. Despite our best efforts to make such an approach scale, this analysis ultimately reveals significant scaling problems, and suggests a new approach to multicast address allocation in the Internet environment.",
"authors": [
{"name": "Mark Handley", "email": "mjh@isi.edu", "affiliation": "USC Information Sciences Institute", "contact": true}
],
@@ -368,7 +368,7 @@
{
"_id_": 29,
"title": "*Core*-Stateless Fair Queueing: Achieving Approximately Fair Bandwidth Allocations in High Speed Networks",
- "abstract": "Router mechanisms designed to achieve fair bandwidth allocations, like Fair Queueing, have many desirable properties for congestion control in the Internet. However, such mechanisms usually need to maintain state, manage buffers, and/or perform packet scheduling on a per ow basis, and this complexity may prevent them from being cost-effectively implemented and widely deployed. In this paper, we propose an architecture that significantly reduces this implementation complexity yet still achieves approximately fair bandwidth allocations. We apply this approach to an island of routers { that is, a contiguous region of the network { and we distinguish between edge routers and core routers. Edge routers maintain per ow state; they estimate the incoming rate of each ow and insert a label into each packet header based on this estimate. Core routers maintain no per ow state; they use FIFO packet scheduling augmented by a probabilistic dropping algorithm that uses the packet labels and an estimate of the aggregate traffic at the router. We call the scheme Core-Stateless Fair Queueing. We present simulations and analysis on the performance of this approach, and discuss an alternate approach.",
+ "abstract": "Router mechanisms designed to achieve fair bandwidth allocations, like Fair Queueing, have many desirable properties for congestion control in the Internet. However, such mechanisms usually need to maintain state, manage buffers, and/or perform packet scheduling on a per ow basis, and this complexity may prevent them from being cost-effectively implemented and widely deployed. In this application, we propose an architecture that significantly reduces this implementation complexity yet still achieves approximately fair bandwidth allocations. We apply this approach to an island of routers { that is, a contiguous region of the network { and we distinguish between edge routers and core routers. Edge routers maintain per ow state; they estimate the incoming rate of each ow and insert a label into each packet header based on this estimate. Core routers maintain no per ow state; they use FIFO packet scheduling augmented by a probabilistic dropping algorithm that uses the packet labels and an estimate of the aggregate traffic at the router. We call the scheme Core-Stateless Fair Queueing. We present simulations and analysis on the performance of this approach, and discuss an alternate approach.",
"authors": [
{"name": "Ion Stoica", "email": "istoica@cs.cmu.edu", "affiliation": "CMU", "contact": true},
{"name": "Scott Shenker", "email": "shenker@parc.xerox.com", "affiliation": "Xerox PARC"},
@@ -380,7 +380,7 @@
{
"_id_": 30,
"title": "Uniform versus Priority Dropping for Layered Video",
- "abstract": "In this paper, we analyze the relative merits of uniform versus priority dropping for the transmission of layered video. We first present our original intuitions about these two approaches, and then investigate the issue more thoroughly through simulations and analysis in which we explicitly model the performance of layered video applications. We compare both their performance characteristics and incentive properties, and find that the performance benefit of priority dropping is smaller than we expected, while uniform dropping has worse incentive properties than we previously believed.",
+ "abstract": "In this application, we analyze the relative merits of uniform versus priority dropping for the transmission of layered video. We first present our original intuitions about these two approaches, and then investigate the issue more thoroughly through simulations and analysis in which we explicitly model the performance of layered video applications. We compare both their performance characteristics and incentive properties, and find that the performance benefit of priority dropping is smaller than we expected, while uniform dropping has worse incentive properties than we previously believed.",
"authors": [
{"name": "Sandeep Bajaj", "email": "bajaj@parc.xerox.com", "affiliation": "Xerox Palo Alto Research Center"},
{"name": "Lee Breslau", "email": "breslau@parc.xerox.com", "affiliation": "Xerox Palo Alto Research Center"},
diff --git a/test/emails.txt b/test/emails.txt
index 91b7e6070..47b797c98 100644
--- a/test/emails.txt
+++ b/test/emails.txt
@@ -1922,7 +1922,7 @@ conference.
Chris Lilley (World Wide Web Consortium)
* Site: http://hotcrp.lcdf.org/test/paper/14?cap={{}}
-0 papers were accepted out of {{}} submissions.
+0 applications were accepted out of {{}} submissions.
Visit the submission site for reviews, comments, and related
information. Reviews and comments are also included below.
@@ -1943,7 +1943,7 @@ Reviewer expertise
------------------
2. Some familiarity
-Paper summary
+Application summary
-------------
Summary V
@@ -1973,7 +1973,7 @@ conference.
Chris Lilley (World Wide Web Consortium)
* Site: http://hotcrp.lcdf.org/test/paper/14?cap={{}}
-0 papers were accepted out of {{}} submissions.
+0 applications were accepted out of {{}} submissions.
Visit the submission site for reviews, comments, and related
information. Reviews and comments are also included below.
diff --git a/test/t_cdb.php b/test/t_cdb.php
index 466352ef4..9217cfd94 100644
--- a/test/t_cdb.php
+++ b/test/t_cdb.php
@@ -237,11 +237,11 @@ function test_author_becomes_contact() {
$ps->save_paper_json((object) [
"id" => 1,
"authors" => ["puneet@catarina.usc.edu", $user_estrin->email,
- $user_floyd->email, $user_van->email, "akhmatova@poema.ru"]
+ $user_floyd->email, $user_van->email, "akhmatova@poema.ruuu"]
]);
$paper1 = $this->user_chair->checked_paper_by_id(1);
- $user_anna = user("akhmatova@poema.ru");
+ $user_anna = user("akhmatova@poema.ruuu");
xassert(!!$user_anna);
xassert($user_anna->act_author_view($paper1));
xassert($user_estrin->act_author_view($paper1));