Files
draft-oran-icnrg-flowblance/draft-oran-icnrg-flowbalance-04.html
2020-08-24 09:55:41 -04:00

1674 lines
83 KiB
HTML
Raw Permalink Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
<!DOCTYPE html>
<html lang="en" class="Internet-Draft">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>Maintaining CCNx or NDN flow balance with highly variable data object sizes</title>
<meta content="Dave Oran" name="author">
<meta content="
Deeply embedded in some ICN architectures, especially Named Data Networking (NDN) and Content-Centric Networking (CCNx) is the notion of flow balance. This captures the idea that there is a one-to-one correspondence between requests for data, carried in Interest messages, and the responses with the requested data object, carried in Data messages. This has a number of highly beneficial properties for flow and congestion control in networks, as well as some desirable security properties. For example, neither legitimate users nor attackers are able to inject large amounts of un-requested data into the network.
Existing congestion control approaches however have a difficult time dealing effectively with a widely varying MTU of ICN data messages, because the protocols allow a dynamic range of 1-64K bytes. Since Interest messages are used to allocate the reverse link bandwidth for returning Data, there is large uncertainty in how to allocate that bandwidth. Unfortunately, most current congestion control schemes in CCNx and NDN only count Interest messages and have no idea how much data is involved that could congest the inverse link. This document proposes a method to maintain flow balance by accommodating the wide dynamic range in Data message size.
" name="description">
<meta content="xml2rfc 2.47.0" name="generator">
<meta content="icn" name="keyword">
<meta content="draft-oran-icnrg-flowbalance-04" name="ietf.draft">
<link href="draft-oran-icnrg-flowbalance-04.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*
NOTE: Changes at the bottom of this file overrides some earlier settings.
Once the style has stabilized and has been adopted as an official RFC style,
this can be consolidated so that style settings occur only in one place, but
for now the contents of this file consists first of the initial CSS work as
provided to the RFC Formatter (xml2rfc) work, followed by itemized and
commented changes found necssary during the development of the v3
formatters.
*/
/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */
@viewport {
zoom: 1.0;
width: extend-to-zoom;
}
@-ms-viewport {
width: extend-to-zoom;
zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
max-width: 90%;
margin: 1.5em auto;
color: #222;
background-color: #fff;
font-size: 14px;
font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
line-height: 1.6;
scroll-behavior: smooth;
}
.ears {
display: none;
}
/* headings */
#title, h1, h2, h3, h4, h5, h6 {
margin: 1em 0 0.5em;
font-weight: bold;
line-height: 1.3;
}
#title {
clear: both;
border-bottom: 1px solid #ddd;
margin: 0 0 0.5em 0;
padding: 1em 0 0.5em;
}
.author {
padding-bottom: 4px;
}
h1 {
font-size: 26px;
margin: 1em 0;
}
h2 {
font-size: 22px;
margin-top: -20px; /* provide offset for in-page anchors */
padding-top: 33px;
}
h3 {
font-size: 18px;
margin-top: -36px; /* provide offset for in-page anchors */
padding-top: 42px;
}
h4 {
font-size: 16px;
margin-top: -36px; /* provide offset for in-page anchors */
padding-top: 42px;
}
h5, h6 {
font-size: 14px;
}
#n-copyright-notice {
border-bottom: 1px solid #ddd;
padding-bottom: 1em;
margin-bottom: 1em;
}
/* general structure */
p {
padding: 0;
margin: 0 0 1em 0;
text-align: left;
}
div, span {
position: relative;
}
div {
margin: 0;
}
.alignRight.art-text {
background-color: #f9f9f9;
border: 1px solid #eee;
border-radius: 3px;
padding: 1em 1em 0;
margin-bottom: 1.5em;
}
.alignRight.art-text pre {
padding: 0;
}
.alignRight {
margin: 1em 0;
}
.alignRight > *:first-child {
border: none;
margin: 0;
float: right;
clear: both;
}
.alignRight > *:nth-child(2) {
clear: both;
display: block;
border: none;
}
svg {
display: block;
}
.alignCenter.art-text {
background-color: #f9f9f9;
border: 1px solid #eee;
border-radius: 3px;
padding: 1em 1em 0;
margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
padding: 0;
}
.alignCenter {
margin: 1em 0;
}
.alignCenter > *:first-child {
border: none;
/* this isn't optimal, but it's an existence proof. PrinceXML doesn't
support flexbox yet.
*/
display: table;
margin: 0 auto;
}
/* lists */
ol, ul {
padding: 0;
margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
margin-left: 1em;
}
li {
margin: 0 0 0.25em 0;
}
.ulCompact li {
margin: 0;
}
ul.empty, .ulEmpty {
list-style-type: none;
}
ul.empty li, .ulEmpty li {
margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
line-height: 100%;
margin: 0 0 0 2em;
}
/* definition lists */
dl {
}
dl > dt {
float: left;
margin-right: 1em;
}
/*
dl.nohang > dt {
float: none;
}
*/
dl > dd {
margin-bottom: .8em;
min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
margin-bottom: 0em;
}
dl > dd > dl {
margin-top: 0.5em;
margin-bottom: 0em;
}
/* links */
a {
text-decoration: none;
}
a[href] {
color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
background-color: transparent;
cursor: default;
} */
/* Figures */
tt, code, pre, code {
background-color: #f9f9f9;
font-family: 'Roboto Mono', monospace;
}
pre {
border: 1px solid #eee;
margin: 0;
padding: 1em;
}
img {
max-width: 100%;
}
figure {
margin: 0;
}
figure blockquote {
margin: 0.8em 0.4em 0.4em;
}
figcaption {
font-style: italic;
margin: 0 0 1em 0;
}
@media screen {
pre {
overflow-x: auto;
max-width: 100%;
max-width: calc(100% - 22px);
}
}
/* aside, blockquote */
aside, blockquote {
margin-left: 0;
padding: 1.2em 2em;
}
blockquote {
background-color: #f9f9f9;
color: #111; /* Arlen: WCAG 2019 */
border: 1px solid #ddd;
border-radius: 3px;
margin: 1em 0;
}
cite {
display: block;
text-align: right;
font-style: italic;
}
/* tables */
table {
width: 100%;
margin: 0 0 1em;
border-collapse: collapse;
border: 1px solid #eee;
}
th, td {
text-align: left;
vertical-align: top;
padding: 0.5em 0.75em;
}
th {
text-align: left;
background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
background-color: #f5f5f5;
}
table caption {
font-style: italic;
margin: 0;
padding: 0;
text-align: left;
}
table p {
/* XXX to avoid bottom margin on table row signifiers. If paragraphs should
be allowed within tables more generally, it would be far better to select on a class. */
margin: 0;
}
/* pilcrow */
a.pilcrow {
color: #666; /* Arlen: AHDJ 2019 */
text-decoration: none;
visibility: hidden;
user-select: none;
-ms-user-select: none;
-o-user-select:none;
-moz-user-select: none;
-khtml-user-select: none;
-webkit-user-select: none;
-webkit-touch-callout: none;
}
@media screen {
aside:hover > a.pilcrow,
p:hover > a.pilcrow,
blockquote:hover > a.pilcrow,
div:hover > a.pilcrow,
li:hover > a.pilcrow,
pre:hover > a.pilcrow {
visibility: visible;
}
a.pilcrow:hover {
background-color: transparent;
}
}
/* misc */
hr {
border: 0;
border-top: 1px solid #eee;
}
.bcp14 {
font-variant: small-caps;
}
.role {
font-variant: all-small-caps;
}
/* info block */
#identifiers {
margin: 0;
font-size: 0.9em;
}
#identifiers dt {
width: 3em;
clear: left;
}
#identifiers dd {
float: left;
margin-bottom: 0;
}
#identifiers .authors .author {
display: inline-block;
margin-right: 1.5em;
}
#identifiers .authors .org {
font-style: italic;
}
/* The prepared/rendered info at the very bottom of the page */
.docInfo {
color: #666; /* Arlen: WCAG 2019 */
font-size: 0.9em;
font-style: italic;
margin-top: 2em;
}
.docInfo .prepared {
float: left;
}
.docInfo .prepared {
float: right;
}
/* table of contents */
#toc {
padding: 0.75em 0 2em 0;
margin-bottom: 1em;
}
nav.toc ul {
margin: 0 0.5em 0 0;
padding: 0;
list-style: none;
}
nav.toc li {
line-height: 1.3em;
margin: 0.75em 0;
padding-left: 1.2em;
text-indent: -1.2em;
}
/* references */
.references dt {
text-align: right;
font-weight: bold;
min-width: 7em;
}
.references dd {
margin-left: 8em;
overflow: auto;
}
.refInstance {
margin-bottom: 1.25em;
}
.references .ascii {
margin-bottom: 0.25em;
}
/* index */
.index ul {
margin: 0 0 0 1em;
padding: 0;
list-style: none;
}
.index ul ul {
margin: 0;
}
.index li {
margin: 0;
text-indent: -2em;
padding-left: 2em;
padding-bottom: 5px;
}
.indexIndex {
margin: 0.5em 0 1em;
}
.index a {
font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
.index ul {
-moz-column-count: 2;
-moz-column-gap: 20px;
}
.index ul ul {
-moz-column-count: 1;
-moz-column-gap: 0;
}
}
/* authors */
address.vcard {
font-style: normal;
margin: 1em 0;
}
address.vcard .nameRole {
font-weight: 700;
margin-left: 0;
}
address.vcard .label {
font-family: "Noto Sans",Arial,Helvetica,sans-serif;
margin: 0.5em 0;
}
address.vcard .type {
display: none;
}
.alternative-contact {
margin: 1.5em 0 1em;
}
hr.addr {
border-top: 1px dashed;
margin: 0;
color: #ddd;
max-width: calc(100% - 16px);
}
/* temporary notes */
.rfcEditorRemove::before {
position: absolute;
top: 0.2em;
right: 0.2em;
padding: 0.2em;
content: "The RFC Editor will remove this note";
color: #9e2a00; /* Arlen: WCAG 2019 */
background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
position: relative;
padding-top: 1.8em;
background-color: #ffd; /* Arlen: WCAG 2019 */
border-radius: 3px;
}
.cref {
background-color: #ffd; /* Arlen: WCAG 2019 */
padding: 2px 4px;
}
.crefSource {
font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
body {
padding-top: 2em;
}
#title {
padding: 1em 0;
}
h1 {
font-size: 24px;
}
h2 {
font-size: 20px;
margin-top: -18px; /* provide offset for in-page anchors */
padding-top: 38px;
}
#identifiers dd {
max-width: 60%;
}
#toc {
position: fixed;
z-index: 2;
top: 0;
right: 0;
padding: 0;
margin: 0;
background-color: inherit;
border-bottom: 1px solid #ccc;
}
#toc h2 {
margin: -1px 0 0 0;
padding: 4px 0 4px 6px;
padding-right: 1em;
min-width: 190px;
font-size: 1.1em;
text-align: right;
background-color: #444;
color: white;
cursor: pointer;
}
#toc h2::before { /* css hamburger */
float: right;
position: relative;
width: 1em;
height: 1px;
left: -164px;
margin: 6px 0 0 0;
background: white none repeat scroll 0 0;
box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
content: "";
}
#toc nav {
display: none;
padding: 0.5em 1em 1em;
overflow: auto;
height: calc(100vh - 48px);
border-left: 1px solid #ddd;
}
}
/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
body {
max-width: 724px;
margin: 42px auto;
padding-left: 1.5em;
padding-right: 29em;
}
#toc {
position: fixed;
top: 42px;
right: 42px;
width: 25%;
margin: 0;
padding: 0 1em;
z-index: 1;
}
#toc h2 {
border-top: none;
border-bottom: 1px solid #ddd;
font-size: 1em;
font-weight: normal;
margin: 0;
padding: 0.25em 1em 1em 0;
}
#toc nav {
display: block;
height: calc(90vh - 84px);
bottom: 0;
padding: 0.5em 0 0;
overflow: auto;
}
img { /* future proofing */
max-width: 100%;
height: auto;
}
}
/* pagination */
@media print {
body {
width: 100%;
}
p {
orphans: 3;
widows: 3;
}
#n-copyright-notice {
border-bottom: none;
}
#toc, #n-introduction {
page-break-before: always;
}
#toc {
border-top: none;
padding-top: 0;
}
figure, pre {
page-break-inside: avoid;
}
figure {
overflow: scroll;
}
h1, h2, h3, h4, h5, h6 {
page-break-after: avoid;
}
h2+*, h3+*, h4+*, h5+*, h6+* {
page-break-before: avoid;
}
pre {
white-space: pre-wrap;
word-wrap: break-word;
font-size: 10pt;
}
table {
border: 1px solid #ddd;
}
td {
border-top: 1px solid #ddd;
}
}
/* This is commented out here, as the string-set: doesn't
pass W3C validation currently */
/*
.ears thead .left {
string-set: ears-top-left content();
}
.ears thead .center {
string-set: ears-top-center content();
}
.ears thead .right {
string-set: ears-top-right content();
}
.ears tfoot .left {
string-set: ears-bottom-left content();
}
.ears tfoot .center {
string-set: ears-bottom-center content();
}
.ears tfoot .right {
string-set: ears-bottom-right content();
}
*/
@page :first {
padding-top: 0;
@top-left {
content: normal;
border: none;
}
@top-center {
content: normal;
border: none;
}
@top-right {
content: normal;
border: none;
}
}
@page {
size: A4;
margin-bottom: 45mm;
padding-top: 20px;
/* The follwing is commented out here, but set appropriately by in code, as
the content depends on the document */
/*
@top-left {
content: 'Internet-Draft';
vertical-align: bottom;
border-bottom: solid 1px #ccc;
}
@top-left {
content: string(ears-top-left);
vertical-align: bottom;
border-bottom: solid 1px #ccc;
}
@top-center {
content: string(ears-top-center);
vertical-align: bottom;
border-bottom: solid 1px #ccc;
}
@top-right {
content: string(ears-top-right);
vertical-align: bottom;
border-bottom: solid 1px #ccc;
}
@bottom-left {
content: string(ears-bottom-left);
vertical-align: top;
border-top: solid 1px #ccc;
}
@bottom-center {
content: string(ears-bottom-center);
vertical-align: top;
border-top: solid 1px #ccc;
}
@bottom-right {
content: '[Page ' counter(page) ']';
vertical-align: top;
border-top: solid 1px #ccc;
}
*/
}
/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
clear: both;
}
/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
vertical-align: top;
}
/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
width: 8em;
}
/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
margin-left: 1em;
}
/* Give floating toc a background color (needed when it's a div inside section */
#toc {
background-color: white;
}
/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
#toc h2 a,
#toc h2 a:link,
#toc h2 a:focus,
#toc h2 a:hover,
#toc a.toplink,
#toc a.toplink:hover {
color: white;
background-color: #444;
text-decoration: none;
}
}
/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
#toc {
padding: 0 0 1em 1em;
}
}
/* Style section numbers with more space between number and title */
.section-number {
padding-right: 0.5em;
}
/* prevent monospace from becoming overly large */
tt, code, pre, code {
font-size: 95%;
}
/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
line-height: 1.12;
}
/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
float: right;
margin-right: 0.5em;
}
/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
float: left;
margin-right: 1em;
}
dl.dlNewline > dt {
float: none;
}
/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
text-align: left;
}
table td.text-center,
table th.text-center {
text-align: center;
}
table td.text-right,
table th.text-right {
text-align: right;
}
/* Make the alternative author contact informatio look less like just another
author, and group it closer with the primary author contact information */
.alternative-contact {
margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
margin: 0 0 0 2em;
}
/* With it being possible to set tables with alignment
left, center, and right, { width: 100%; } does not make sense */
table {
width: auto;
}
/* Avoid reference text that sits in a block with very wide left margin,
because of a long floating dt label.*/
.references dd {
overflow: visible;
}
/* Control caption placement */
caption {
caption-side: bottom;
}
/* Limit the width of the author address vcard, so names in right-to-left
script don't end up on the other side of the page. */
address.vcard {
max-width: 30em;
margin-right: auto;
}
/* For address alignment dependent on LTR or RTL scripts */
address div.left {
text-align: left;
}
address div.right {
text-align: right;
}
/* Provide table alignment support. We can't use the alignX classes above
since they do unwanted things with caption and other styling. */
table.right {
margin-left: auto;
margin-right: 0;
}
table.center {
margin-left: auto;
margin-right: auto;
}
table.left {
margin-left: 0;
margin-right: auto;
}
/* Give the table caption label the same styling as the figcaption */
caption a[href] {
color: #222;
}
@media print {
.toplink {
display: none;
}
/* avoid overwriting the top border line with the ToC header */
#toc {
padding-top: 1px;
}
/* Avoid page breaks inside dl and author address entries */
.vcard {
page-break-inside: avoid;
}
}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
font-variant: small-caps;
font-weight: bold;
font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
h2 {
margin-top: -18px; /* provide offset for in-page anchors */
padding-top: 31px;
}
h3 {
margin-top: -18px; /* provide offset for in-page anchors */
padding-top: 24px;
}
h4 {
margin-top: -18px; /* provide offset for in-page anchors */
padding-top: 24px;
}
/* Float artwork pilcrow to the right */
@media screen {
.artwork a.pilcrow {
display: block;
line-height: 0.7;
margin-top: 0.15em;
}
}
/* Make pilcrows on dd visible */
@media screen {
dd:hover > a.pilcrow {
visibility: visible;
}
}
/* Make the placement of figcaption match that of a table's caption
by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
possibly even requiring a new line */
@media print {
a.pilcrow {
display: none;
}
}
/* Styling for the external metadata */
div#external-metadata {
background-color: #eee;
padding: 0.5em;
margin-bottom: 0.5em;
display: none;
}
div#internal-metadata {
padding: 0.5em; /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
clear: both;
margin: 0 0 -1em;
padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
margin-bottom: 0.25em;
min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
border-left: 1px solid #ddd;
margin: 1em 0 1em 2em;
padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
figcaption, table caption {
page-break-before: avoid;
}
}
/* Font size adjustments for print */
@media print {
body { font-size: 10pt; line-height: normal; max-width: 96%; }
h1 { font-size: 1.72em; padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
h2 { font-size: 1.44em; padding-top: 1.5em; } /* 1*1.2*1.2 */
h3 { font-size: 1.2em; padding-top: 1.5em; } /* 1*1.2 */
h4 { font-size: 1em; padding-top: 1.5em; }
h5, h6 { font-size: 1em; margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
.artwork,
.sourcecode {
margin-bottom: 1em;
}
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
border: 1px solid #ddd;
}
td {
border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
#toc nav { display: none; }
#toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
break-after: avoid-page;
break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode {
break-before: avoid-page;
break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
break-before: auto;
break-inside: auto;
}
dt {
break-before: auto;
break-after: avoid-page;
}
dd {
break-before: avoid-page;
break-after: auto;
orphans: 3;
widows: 3
}
span.break, dd.break {
margin-bottom: 0;
min-height: 0;
break-before: auto;
break-inside: auto;
break-after: auto;
}
/* Undo break-before ToC */
@media print {
#toc {
break-before: auto;
}
}
/* Text in compact lists should not get extra bottim margin space,
since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
margin-bottom: 1em; /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
backgrounds. Changed to something a bit more selective. */
tt, code {
background-color: transparent;
}
p tt, p code, li tt, li code {
background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact {
line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
margin-top: initial;
}</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
</head>
<body>
<script src="metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">Internet-Draft</td>
<td class="center">Maintaining Flow Balance</td>
<td class="right">August 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Oran</td>
<td class="center">Expires 25 February 2021</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-workgroup">Workgroup:</dt>
<dd class="workgroup">ICNRG</dd>
<dt class="label-internet-draft">Internet-Draft:</dt>
<dd class="internet-draft">draft-oran-icnrg-flowbalance-04</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-08-24" class="published">24 August 2020</time>
</dd>
<dt class="label-intended-status">Intended Status:</dt>
<dd class="intended-status">Experimental</dd>
<dt class="label-expires">Expires:</dt>
<dd class="expires"><time datetime="2021-02-25">25 February 2021</time></dd>
<dt class="label-authors">Author:</dt>
<dd class="authors">
<div class="author">
<div class="author-name">D. Oran</div>
<div class="org">Network Systems Research and Design</div>
</div>
</dd>
</dl>
</div>
<h1 id="title">Maintaining CCNx or NDN flow balance with highly variable data object sizes</h1>
<section id="section-abstract">
<h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">Deeply embedded in some ICN architectures, especially Named Data Networking (NDN) and Content-Centric Networking (CCNx) is the notion of flow balance. This captures the idea that there is a one-to-one correspondence between requests for data, carried in Interest messages, and the responses with the requested data object, carried in Data messages. This has a number of highly beneficial properties for flow and congestion control in networks, as well as some desirable security properties. For example, neither legitimate users nor attackers are able to inject large amounts of un-requested data into the network.<a href="#section-abstract-1" class="pilcrow"></a></p>
<p id="section-abstract-2">Existing congestion control approaches however have a difficult time dealing effectively with a widely varying MTU of ICN data messages, because the protocols allow a dynamic range of 1-64K bytes. Since Interest messages are used to allocate the reverse link bandwidth for returning Data, there is large uncertainty in how to allocate that bandwidth. Unfortunately, most current congestion control schemes in CCNx and NDN only count Interest messages and have no idea how much data is involved that could congest the inverse link. This document proposes a method to maintain flow balance by accommodating the wide dynamic range in Data message size.<a href="#section-abstract-2" class="pilcrow"></a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
<h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
</h2>
<p id="section-boilerplate.1-1">
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.<a href="#section-boilerplate.1-1" class="pilcrow"></a></p>
<p id="section-boilerplate.1-2">
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is
at <span><a href="https://datatracker.ietf.org/drafts/current/">https://datatracker.ietf.org/drafts/current/</a></span>.<a href="#section-boilerplate.1-2" class="pilcrow"></a></p>
<p id="section-boilerplate.1-3">
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow"></a></p>
<p id="section-boilerplate.1-4">
This Internet-Draft will expire on 25 February 2021.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
<h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
</h2>
<p id="section-boilerplate.2-1">
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow"></a></p>
<p id="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.<a href="#section-boilerplate.2-2" class="pilcrow"></a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
<a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
</h2>
<nav class="toc"><ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.1">
<p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow"></a></p>
</li>
<li class="toc compact ulEmpty" id="section-toc.1-1.2">
<p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a><a href="#section-toc.1-1.2.1" class="pilcrow"></a></p>
</li>
<li class="toc compact ulEmpty" id="section-toc.1-1.3">
<p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-method-to-enhance-congestio" class="xref">Method to enhance congestion control with signaled size information in Interest Messages</a><a href="#section-toc.1-1.3.1" class="pilcrow"></a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.3.2.1">
<p id="section-toc.1-1.3.2.1.1" class="keepWithNext"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-how-to-predict-the-size-of-" class="xref">How to predict the size of returning Data messages</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow"></a></p>
</li>
<li class="toc compact ulEmpty" id="section-toc.1-1.3.2.2">
<p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-handling-too-big-cases" class="xref">Handling 'too big' cases</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow"></a></p>
</li>
<li class="toc compact ulEmpty" id="section-toc.1-1.3.2.3">
<p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-handling-too-small-cases" class="xref">Handling 'too small' cases</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow"></a></p>
</li>
<li class="toc compact ulEmpty" id="section-toc.1-1.3.2.4">
<p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-interactions-with-interest-" class="xref">Interactions with Interest Aggregation</a><a href="#section-toc.1-1.3.2.4.1" class="pilcrow"></a></p>
</li>
<li class="toc compact ulEmpty" id="section-toc.1-1.3.2.5">
<p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>.  <a href="#name-operation-when-some-interes" class="xref">Operation when some Interests lack the expected data size option and some have it</a><a href="#section-toc.1-1.3.2.5.1" class="pilcrow"></a></p>
</li>
</ul>
</li>
<li class="toc compact ulEmpty" id="section-toc.1-1.4">
<p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-dealing-with-malicious-acto" class="xref">Dealing with malicious actors</a><a href="#section-toc.1-1.4.1" class="pilcrow"></a></p>
</li>
<li class="toc compact ulEmpty" id="section-toc.1-1.5">
<p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-mapping-to-ccnx-and-ndn-pac" class="xref">Mapping to CCNx and NDN packet encodings</a><a href="#section-toc.1-1.5.1" class="pilcrow"></a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.5.2.1">
<p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-packet-encoding-for-ccnx" class="xref">Packet encoding for CCNx</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow"></a></p>
</li>
<li class="toc compact ulEmpty" id="section-toc.1-1.5.2.2">
<p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-packet-encoding-for-ndn" class="xref">Packet encoding for NDN</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow"></a></p>
</li>
</ul>
</li>
<li class="toc compact ulEmpty" id="section-toc.1-1.6">
<p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.6.1" class="pilcrow"></a></p>
</li>
<li class="toc compact ulEmpty" id="section-toc.1-1.7">
<p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow"></a></p>
</li>
<li class="toc compact ulEmpty" id="section-toc.1-1.8">
<p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.8.1" class="pilcrow"></a></p>
</li>
<li class="toc compact ulEmpty" id="section-toc.1-1.9">
<p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.9.1" class="pilcrow"></a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.9.2.1">
<p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow"></a></p>
</li>
<li class="toc compact ulEmpty" id="section-toc.1-1.9.2.2">
<p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow"></a></p>
</li>
</ul>
</li>
<li class="toc compact ulEmpty" id="section-toc.1-1.10">
<p id="section-toc.1-1.10.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-authors-address" class="xref">Author's Address</a><a href="#section-toc.1-1.10.1" class="pilcrow"></a></p>
</li>
</ul>
</nav>
</section>
</div>
<div id="intro">
<section id="section-1">
<h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
</h2>
<p id="section-1-1">Deeply embedded in some ICN architectures, especially Named Data Networking (<span>[<a href="#NDN" class="xref">NDN</a>]</span>) and Content-Centric Networking (CCNx <span>[<a href="#RFC8569" class="xref">RFC8569</a>]</span>,<span>[<a href="#RFC8609" class="xref">RFC8609</a>]</span>) is the notion of <em>flow balance</em>. This captures the idea that there is a one-to-one correspondence between requests for data, carried in Interest messages, and the responses with the requested data object, carried in Data messages. This has a number of highly beneficial properties for flow and congestion control in networks, as well as some desirable security properties. For example, neither legitimate users nor attackers are able to inject large amounts of un-requested data into the network.<a href="#section-1-1" class="pilcrow"></a></p>
<p id="section-1-2">This approach leads to a desire to make the size of the objects carried in Data messages small and near constant, because flow balance can then be kept using simple bookkeeping of how many Interest messages are outstanding. While simple, constraining Data messages to be quite small - usually on the order of a link Maximum Transmission Unit (MTU) - has some constraints and deleterious effects, among which are:<a href="#section-1-2" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-1-3.1">Such small data objects are inconvenient for many applications; their natural data object sizes can be considerably larger than a link MTU.<a href="#section-1-3.1" class="pilcrow"></a>
</li>
<li class="normal" id="section-1-3.2">Applications with truly small data objects (e.g. voice packets in an Internet telephony applications) have no way to communicate that to the network, causing resources to still be allocated for MTU-sized data objects<a href="#section-1-3.2" class="pilcrow"></a>
</li>
<li class="normal" id="section-1-3.3">When chunking a larger data object into multiple Data messages, each message has to be individually cryptographically hashed and signed, increasing both computational overhead and overall message header size. The signature can be elided when Manifests are used (by signing the Manifest instead), but the overhead of hashing multiple small messages rather than fewer larger ones remains.<a href="#section-1-3.3" class="pilcrow"></a>
</li>
</ul>
<p id="section-1-4">One approach which helps with the last of these is to employ fragmentation for Data messages larger than the Path MTU (PMTU). Such messages are carved into smaller pieces for transmission over the link(s). There are three flavors of fragmentation: end-to-end, hop-by-hop with reassembly at every hop, and hop-by-hop with cut-through of individual fragments. A number of ICN protocol architectures incorporate fragmentation and schemes have been proposed for both NDN and CCNx, for example in <span>[<a href="#Ghali2013" class="xref">Ghali2013</a>]</span>. Fragmentation alone does not ameliorate the flow balance problem however, since from a resource allocation standpoint both memory and link bandwidth must be set aside for maximum-sized data objects to avoid congestion collapse under overload.<a href="#section-1-4" class="pilcrow"></a></p>
<p id="section-1-5">The design space considered in this document does not however extend to arbitrarily large objects (e.g. 100's of kilobytes or larger). As the dynamic range of data object sizes gets very large, finding the right tradeoff between handling a large number of small data objects versus a single very large data object when allocating link and buffer resources becomes intractable. Further, the semantics of Interest-Data exchanges means that any error in the exchange results in a re-issue of an Interest for the entire Data object. Very large data objects represent a performance problem because the cost of retransmission when Interests are retransmitted (or re-issued) becomes unsustainably high. Therefore, the method we propose deals with a dynamic range of object sizes from very small (a fraction of a link MTU) to moderately large - about 64 kilobytes or equivalently about 40 Ethernet packets, and assumes an associated fragmentation scheme to handle link MTUs that cannot carry the Data message in a single link-layer packet.<a href="#section-1-5" class="pilcrow"></a></p>
<p id="section-1-6">The approach described in the rest of this document maintains flow balance under the conditions outlined above by allocating resources accurately based on expected Data message size, rather than employing simple interest counting.<a href="#section-1-6" class="pilcrow"></a></p>
</section>
</div>
<section id="section-2">
<h2 id="name-requirements-language">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
</h2>
<p id="section-2-1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <span><a href="#RFC2119" class="xref">RFC 2119</a> [<a href="#RFC2119" class="xref">RFC2119</a>]</span>.<a href="#section-2-1" class="pilcrow"></a></p>
</section>
<div id="description">
<section id="section-3">
<h2 id="name-method-to-enhance-congestio">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-method-to-enhance-congestio" class="section-name selfRef">Method to enhance congestion control with signaled size information in Interest Messages</a>
</h2>
<p id="section-3-1">Before diving into the specifics of the design, it is useful to consider how congestion control works in NDN/CCNx. Unlike the IP protocol family, which relies on end-to-end congestion control (e.g. TCP<span>[<a href="#RFC0793" class="xref">RFC0793</a>]</span>, DCCP<span>[<a href="#RFC4340" class="xref">RFC4340</a>]</span>, SCTP<span>[<a href="#RFC4960" class="xref">RFC4960</a>]</span>, QUIC<span>[<a href="#I-D.ietf-quic-transport" class="xref">I-D.ietf-quic-transport</a>]</span>), CCNx and NDN employ hop-by-hop congestion control. There is per-Interest/Data state at every hop of the path and therefore for each outstanding Interest, bandwidth for data returning on the inverse path can be allocated. In many current designs, this allocation is done using simple Interest counting - by queueing and subsequently forwarding one Interest message from a downstream node, implicitly this provides a guarantee (either hard or soft) that there is sufficient bandwidth on the inverse direction of the link to send back one Data message. A number of congestion control schemes have been developed that operate in this fashion, for example <span>[<a href="#Wang2013" class="xref">Wang2013</a>]</span>,<span>[<a href="#Mahdian2016" class="xref">Mahdian2016</a>]</span>,<span>[<a href="#Song2018" class="xref">Song2018</a>]</span>,<span>[<a href="#Carofiglio2012" class="xref">Carofiglio2012</a>]</span>. Other schemes, like <span>[<a href="#Schneider2016" class="xref">Schneider2016</a>]</span> neither count nor police interests, but instead monitor queues using AQM (active queue management) to mark or drop returning Data packets that have experienced congestion. It is worth noting that every congestion control algorithm has an explicit fairness goal and associated objective function (usually either <span>[<a href="#minmaxfairness" class="xref">minmaxfairness</a>]</span> or <span>[<a href="#proportionalfairness" class="xref">proportionalfairness</a>]</span>). If your fairness is to be based on resource usage, pure interest counting doesn't do the trick, since a consumer asking for large thing can saturate a link and shift loss to consumers asking for small things.<a href="#section-3-1" class="pilcrow"></a></p>
<p id="section-3-2">In order to deal with a larger dynamic range of Data message size, some means is required to allocate link bandwidth for Data messages in bytes with an upper bound larger than a Path MTU and a lower bound lower than a single link MTU. Since resources are allocated for returning Data based on arriving Interests, this information must be available in Interest messages.<a href="#section-3-2" class="pilcrow"></a></p>
<p id="section-3-3">Therefore, one key idea is the inclusion of an <em>expected data size</em> TLV in each Interest message. This allows each forwarder on the path taken by the Interest to more accurately allocate bandwidth on the inverse path for the returning Data message. Also, by including the expected data size, large objects will have a corresponding weight in resource allocation, maintaining link and forwarder buffering fairness. The simpler Interest counting scheme was nominally "fair" on a per-exchange basis within the variations of data that fit in a single PMTU packet because all Interests produced similar amounts of data in return. In the absence of such a field, it is not feasible to allow a large dynamic range in object size. While schemes like <span>[<a href="#Schneider2016" class="xref">Schneider2016</a>]</span> would not employ the expected data size to allocate reverse link bandwidth, they can still benefit from the information to affect the AQM congestion marking algorithm, preferentially marking data packets that exceed the expected data size from the corresponding Interest.<a href="#section-3-3" class="pilcrow"></a></p>
<p id="section-3-4">It is natural to ask whether the additional complexity introduced into an ICN forwarder, and the additional computational cost for the congestion control operations is worthwhile. For congestion control schemes like <span>[<a href="#Schneider2016" class="xref">Schneider2016</a>]</span> the additional overhead is not trivial, since no Interest counting is happening. However, if a congestion control is <em>already</em> counting Interests, the additional overhead is minimal, only reading one extra TLV from the Interest and incrementing the outstanding data amount for the corresponding queue by that number rather than a constant of 1. The overhead on returning data is simply reducing the amount by the actual Data message size, rather than by 1.<a href="#section-3-4" class="pilcrow"></a></p>
<div id="prediction">
<section id="section-3.1">
<h3 id="name-how-to-predict-the-size-of-">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-how-to-predict-the-size-of-" class="section-name selfRef">How to predict the size of returning Data messages</a>
</h3>
<p id="section-3.1-1">This of course raises the question "How does the requester know how big the corresponding Data message coming back will be?". For a number of important applications, the size is known a priori due to the characteristics of the application. Here are some examples:<a href="#section-3.1-1" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-3.1-2.1">For many sensor and other Internet-of-Things applications, the data is instrument readings which have fixed known size.<a href="#section-3.1-2.1" class="pilcrow"></a>
</li>
<li class="normal" id="section-3.1-2.2">In video streaming, the data is output of a video encoder which produces variable sized frames. This information is typically made available ahead of time to the streaming clients in the form of a <em>Manifest</em> (e.g <span>[<a href="#DASH" class="xref">DASH</a>]</span>, <span><a href="#I-D.irtf-icnrg-flic" class="xref">FLIC</a> [<a href="#I-D.irtf-icnrg-flic" class="xref">I-D.irtf-icnrg-flic</a>]</span>), which contains the names of the corresponding segments (or individual frames) of video and audio and their sizes.<a href="#section-3.1-2.2" class="pilcrow"></a>
</li>
<li class="normal" id="section-3.1-2.3">Internet telephony applications use vocoders that typically employ fixed-size audio frames. Therefore, their size is known either a priori, or via an initialization exchange at the start of an audio session.<a href="#section-3.1-2.3" class="pilcrow"></a>
</li>
</ul>
<p id="section-3.1-3">The more complex cases arise where the data size is not known at the time the Interest must be sent. Much of the nuance of the proposed scheme is in how mismatches between the expected data size and the actual Data message returned are handled. The consumer can either under- or over-estimate the data size. In the former case, the under-estimate can lead to congestion and possible loss of data. In the latter case, bandwidth that could have been used by data objects requested by other consumers might be wasted. We first consider "honest" mis-estimates due to imperfect knowledge by the ICN application; later we consider malicious applications that are using the machinery to mount some form of attack. We also consider the effects of Interest aggregation if the aggregated Interests have differing expected data sizes. Also, it should be obvious that if the Data message arrives, the application learns its actual size, which may or may not be useful in adjusting the expected data size estimate for future Interests.<a href="#section-3.1-3" class="pilcrow"></a></p>
<p id="section-3.1-4">In all cases, the expected data size from the Interest can be incorporated in the corresponding Pending Interest Table (PIT) entry of each CCNx/NDN forwarder on the path and hence when a (possibly fragmented) Data object comes back, its total size is known and can be compared to the expected size in the PIT for a mismatch. Aside: In the case of fragmentation, we assume a fragmentation scheme in which the total Data message size can be known as soon as any one fragment is received (a reasonable assumption for most any well-designed fragmentation method, such as that in <span>[<a href="#Ghali2013" class="xref">Ghali2013</a>]</span>).<a href="#section-3.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="toobig">
<section id="section-3.2">
<h3 id="name-handling-too-big-cases">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-handling-too-big-cases" class="section-name selfRef">Handling 'too big' cases</a>
</h3>
<p id="section-3.2-1">If the returning Data message is larger than the expected data size, the extra data could result in either unfair bandwidth allocation or possibly data loss under congestion conditions. When this is detected, the forwarder has three choices:<a href="#section-3.2-1" class="pilcrow"></a></p>
<ol start="1" type="1" class="normal type-1" id="section-3.2-2">
<li id="section-3.2-2.1">It could forward the Data message anyway, which is safe under non-congestion conditions, but unfair and possibly unstable when the output link is congested<a href="#section-3.2-2.1" class="pilcrow"></a>
</li>
<li id="section-3.2-2.2">It could forward the data when un-congested (e.g. by assessing output queue depth) but drop it when congested<a href="#section-3.2-2.2" class="pilcrow"></a>
</li>
<li id="section-3.2-2.3">It could always drop the data, as a way of "punishing" the requester for the mis-estimate.<a href="#section-3.2-2.3" class="pilcrow"></a>
</li>
</ol>
<p id="section-3.2-3">Either of the latter two strategies is acceptable from a congestion control point of view. However, it is not a good idea to simply drop the Data message with no feedback to the issuer of the Interest because the application has no way to learn the actual data size and retry. Further, recovery would be delayed until the failing Interest timed out. Therefore, an additional element needed in protocol semantics is the incorporation of a "Data too big" error message (achieved via the use of an "Interest Return" packet in CCNx).<a href="#section-3.2-3" class="pilcrow"></a></p>
<p id="section-3.2-4">Upon dropping data as above, the CCNx/NDN forwarder converts the normal Data message into an Interest Return packet containing the existing <span>[<a href="#RFC8609" class="xref">RFC8609</a>]</span> T_MTU_TOO_LARGE error code and the actual size of the Data message instead of the original content. It propagates that back toward the client identically to how the original Data message would have been handled. Subsequent nodes upon receiving the T_MTU_TOO_LARGE error treat identically to other Interest Return errors. When the Interest Return eventually arrives back to the issuer of the Interest, the user MAY reissue the Interest with the correct expected data size.<a href="#section-3.2-4" class="pilcrow"></a></p>
<p id="section-3.2-5">One detail to note is that an Interest Return carrying T_MTU_TOO_LARGE must be deterministically smaller than the expected data size in all cases. This is clearly the case for large data objects, but there is a corner case with small data objects. There has to be a minimum expected data size that a client can specify in their Interests, and that minimum cannot be smaller than the size of a T_MTU_TOO_LARGE Interest Return packet.<a href="#section-3.2-5" class="pilcrow"></a></p>
</section>
</div>
<div id="toosmall">
<section id="section-3.3">
<h3 id="name-handling-too-small-cases">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-handling-too-small-cases" class="section-name selfRef">Handling 'too small' cases</a>
</h3>
<p id="section-3.3-1">Next we consider the case where the returning data is smaller than the expected data size. While this case does not result in congestion, it can cause resources to be inefficiently allocated because not all of the set-aside bandwidth for the returning data object gets used. The simplest and most straightforward way to deal with this case is to essentially ignore it. The motivation for not worrying about the smaller data mismatch is that in many situations that employ usage-based resource measurement (and possibly charging), it is trivial to just account for the usage according to the larger expected data size rather than actual returned data size. Properly adjusting congestion control parameters to somehow penalize users for over-estimating their resource usage requires fairly heavyweight machinery, which in most cases is not warranted. If desired, any of the following mechanisms could be considered:<a href="#section-3.3-1" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-3.3-2.1">Attempt to identify future Interests for the same object or closely related objects and allocate resources based on some retained state about the actual size of prior objects<a href="#section-3.3-2.1" class="pilcrow"></a>
</li>
<li class="normal" id="section-3.3-2.2">Police consumer behavior and decrease the expected data size in one or more future Interests to compensate<a href="#section-3.3-2.2" class="pilcrow"></a>
</li>
<li class="normal" id="section-3.3-2.3">For small objects, do more optimistic resource allocation on the links on the presumption that there will be some "slack" due to clients overestimating data object size.<a href="#section-3.3-2.3" class="pilcrow"></a>
</li>
</ul>
</section>
</div>
<div id="aggregation">
<section id="section-3.4">
<h3 id="name-interactions-with-interest-">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-interactions-with-interest-" class="section-name selfRef">Interactions with Interest Aggregation</a>
</h3>
<p id="section-3.4-1">One protocol detail of CCNx/NDN that needs to be dealt with is Interest Aggregation. Interest Aggregation, while a powerful feature for maintaining flow balance when multiple consumers send Interests for the same Named object, introduces subtle complications. Whenever a second or subsequent Interest arrives at a forwarder with an active PIT entry it is possible that those Interests carry different parameters, for example hop limit, payload, etc. It is therefore necessary to specify the exact behavior of the forwarder for each of the parameters that might differ. In the case of the expected data size parameter defined here, the value is associated with the ingress face on which the Interest creating the PIT entry arrived, as opposed to being global to the PIT entry as a whole. Interest aggregation interacts with expected data size if Interests from different clients contain different values of the expected data size. As above in <a href="#toosmall" class="xref">Section 3.3</a>, the simplest solution to this problem is to ignore it, as most error cases are benign. However, there is one problematic error case where one client provides an accurate expected data size, but another who issued the Interest first underestimates, causing both to receive a T_MTU_TOO_LARGE error. This introduces a denial of service vulnerability, which we discuss below together with the other malicious actor cases.<a href="#section-3.4-1" class="pilcrow"></a></p>
<p id="section-3.4-2">There are two cases to consider:<a href="#section-3.4-2" class="pilcrow"></a></p>
<ol start="1" type="1" class="normal type-1" id="section-3.4-3">
<li id="section-3.4-3.1">The arriving Interest carries an expected data size smaller than any of the values associated with the PIT entry.<a href="#section-3.4-3.1" class="pilcrow"></a>
</li>
<li id="section-3.4-3.2">The arriving Interest carries an expected data size larger than any of the values associated with the PIT entry.<a href="#section-3.4-3.2" class="pilcrow"></a>
</li>
</ol>
<p id="section-3.4-4">For Case (1) the Interest can be safely aggregated since the upstream links will have sufficient bandwidth allocated based on the larger expected data size (assuming the original Interest's expected data size was itself sufficiently large to accommodate the actual size of the returning Data). On the other hand, should the incoming face have bandwidth allocated based on the larger existing Interest's expected data size, or on the smaller value in the arriving interest? Here there are two possible approaches:<a href="#section-3.4-4" class="pilcrow"></a></p>
<ol start="1" type="a" class="normal type-a" id="section-3.4-5">
<li id="section-3.4-5.1">Allocate based on the data size already in the PIT. In this case the consumer sending the earlier Interest can cause over-allocation of link bandwidth for other incoming faces, but there will not be a T_MTU_TOO_LARGE error generated for that Interest<a href="#section-3.4-5.1" class="pilcrow"></a>
</li>
<li id="section-3.4-5.2">Allocate based on the value in the arriving Interest. If the returning Data is in fact larger, generate a T_MTU_TOO_LARGE Interest Return on that ingress face, while successfully returning the Data message on any faces that do not exhibit a too small expected data size<a href="#section-3.4-5.2" class="pilcrow"></a>
</li>
</ol>
<p id="section-3.4-6">It is RECOMMENDED that the second policy be followed. The reasons behind this recommendation are as follows:<a href="#section-3.4-6" class="pilcrow"></a></p>
<ol start="1" type="1" class="normal type-1" id="section-3.4-7">
<li id="section-3.4-7.1">The link can be congested quite quickly after the queuing decision is made, especially if the data has a long link-occupancy time, so this is a safer alternative.<a href="#section-3.4-7.1" class="pilcrow"></a>
</li>
<li id="section-3.4-7.2">The cost of returning the error is only one link RTT, since the consumer (or downstream forwarder) can immediately re-issue the Interest with the correct size and perhaps pick up the cached object from the upstream forwarder's Content Store.<a href="#section-3.4-7.2" class="pilcrow"></a>
</li>
<li id="section-3.4-7.3">Being optimistic and returning the data interacts with the behavior of aggregate resource control and resource accounting, which in turn raises the messy issue of whether to "charge" the consumer for the actual bandwidth used or only for the requested bandwidth in the expected data.<a href="#section-3.4-7.3" class="pilcrow"></a>
</li>
<li id="section-3.4-7.4">The rabbit hole goes deeper if you add differential QoS to the equation or consumers "playing games" and intentionally underestimating so their interests get satisfied when links aren't congested. This makes handling malicious actors (<a href="#malicious" class="xref">Section 4</a>) more difficult.<a href="#section-3.4-7.4" class="pilcrow"></a>
</li>
</ol>
<p id="section-3.4-8">For Case (2) above, the Interest MUST be forwarded rather than aggregated to prevent a consumer from mounting a denial of service attack by sending intentionally too small expected data size (see <a href="#malicious" class="xref">Section 4</a> for additional detail on this and other attacks). As above for Case (1) it is RECOMMENDED that policy (b) above be followed.<a href="#section-3.4-8" class="pilcrow"></a></p>
</section>
</div>
<div id="compatibility">
<section id="section-3.5">
<h3 id="name-operation-when-some-interes">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-operation-when-some-interes" class="section-name selfRef">Operation when some Interests lack the expected data size option and some have it</a>
</h3>
<p id="section-3.5-1">Since the expected data size is an optional hop-by-hop packet field, forwarders need to be prepared to handle an arbitrary mix of packets containing or lacking this option. There are two general things to address.<a href="#section-3.5-1" class="pilcrow"></a></p>
<p id="section-3.5-2">First, we assume that any forwarder supporting expected data size is running a more sophisticated congestion control algorithm that one employing simple interest counting. The link bandwidth resource allocation is therefore based directly, or indirectly, on the expected Data size in bytes. Therefore, the forwarder has to assign a value to use in the resource allocation for the reverse link. This specification does not mandate any particular approach or a default value to use. However, in the absence on other guidance, it makes sense to do one of two things:<a href="#section-3.5-2" class="pilcrow"></a></p>
<ol start="1" type="1" class="normal type-1" id="section-3.5-3">
<li id="section-3.5-3.1">Pick a default based on the link MTU of the face on which the Interest arrived and use that for all Interests lacking an expected data size. This is likely to be most compatible with simple interest counting which would rate limit all incoming interests equally.<a href="#section-3.5-3.1" class="pilcrow"></a>
</li>
<li id="section-3.5-3.2">
<p id="section-3.5-3.2.1">Configure some values for given Name prefixes that have known sizes. This may be appropriate for dedicated forwarders supporting single use cases, such as:<a href="#section-3.5-3.2.1" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-3.5-3.2.2.1">A forwarder handling IoT sensors sending very small Data messages<a href="#section-3.5-3.2.2.1" class="pilcrow"></a>
</li>
<li class="normal" id="section-3.5-3.2.2.2">A forwarder handling real-time video with large average Data packets that exceed link MTU and are routinely fragmented<a href="#section-3.5-3.2.2.2" class="pilcrow"></a>
</li>
<li class="normal" id="section-3.5-3.2.2.3">A forwarder doing voice trunking where the vocoders produce moderate sized packets, still much smaller than the link MTU<a href="#section-3.5-3.2.2.3" class="pilcrow"></a>
</li>
</ul>
</li>
</ol>
<p id="section-3.5-4">The second area to address is what to do if an interest lacking an expected Data size is responded to by a Data message whose size exceeds the default discussed above. It would be inappropriate to issue a T_MTU_TOO_LARGE error, since the consumer is unlikely to understand or deal correctly with that new error case. Instead, it is RECOMMENDED that the forwarder:<a href="#section-3.5-4" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-3.5-5.1">Ignore the mismatch if the reverse link is not congested and return the requested Data message anyway.<a href="#section-3.5-5.1" class="pilcrow"></a>
</li>
<li class="normal" id="section-3.5-5.2">If the reverse link is congested, issue an Interest Return with the T_NO_RESOURCES error code<a href="#section-3.5-5.2" class="pilcrow"></a>
</li>
</ul>
<p id="section-3.5-6">This specification does not define or recommend any particular algorithm for assessing the congestion state of the link(s) to carry the Data message downstream to the requesting consumers. It is assumed that a reasonable algorithm is in use, because otherwise even basic Interest counting forms of congestion control would not be effective.<a href="#section-3.5-6" class="pilcrow"></a></p>
</section>
</div>
</section>
</div>
<div id="malicious">
<section id="section-4">
<h2 id="name-dealing-with-malicious-acto">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-dealing-with-malicious-acto" class="section-name selfRef">Dealing with malicious actors</a>
</h2>
<p id="section-4-1">First we note that various known attacks in CCNx or NDN can also be mounted by users employing this method. Attacks that involve interest flooding, cache pollution, cache poisoning, etc. are neither worsened nor ameliorated by the introduction of the congestion control capabilities described here. However, there are two new vulnerabilities that need to be dealt with. These two new vulnerabilities involve intentional mis-estimation of data size.<a href="#section-4-1" class="pilcrow"></a></p>
<p id="section-4-2">The first is a consumer who intentionally over-estimates data size with the goal of preventing other users from using the bandwidth. This is at most a minor additional concern given the discussion of how to handle over-estimation by honest clients in <a href="#toobig" class="xref">Section 3.2</a>. If one of the amelioration techniques described there is used, the case of malicious over-estimation is also dealt with adequately.<a href="#section-4-2" class="pilcrow"></a></p>
<p id="section-4-3">The second is a user who intentionally under-estimates the data size with the goal having its Interest processed while the other aggregated interests are not processed, thereby causing T_MTU_TOO_LARGE errors and denying service to the other users with overlapping requests. There are a number of possible mitigation techniques for this attack vector, ranging in complexity. We outline two below; there may be others as or more effective with acceptable complexity and overhead:<a href="#section-4-3" class="pilcrow"></a></p>
<ul class="normal">
<li class="normal" id="section-4-4.1">(Simplest) A user sending Interests resulting in a T_MTU_TOO_LARGE error is treated similarly to users mounting interest flooding attacks; the a router aggregating Interests with differing expected data sizes rate limits the face(s) exhibiting these errors, thus decreasing the ability of a user to issue enough mis-estimated Interests to collide and generate Interest aggregation.<a href="#section-4-4.1" class="pilcrow"></a>
</li>
<li class="normal" id="section-4-4.2">An ICN forwarder aggregating Interests remembers in the PIT entry not only the expected data size of the Interest it forwarded, but the maximum of the expected data size of the other Interests it aggregated. If a T_MTU_TOO_LARGE error comes back, instead of propagating it, the forwarder MAY treat this as a transient error, drop the Interest Return, and re-forward the Interest using the maximum expected data size in the PIT (assuming it is is bigger). This recovers from the error, but the attacker can still cause an extra round trip to the producer or to an upstream forwarder with a copy of the data in its Content Store.<a href="#section-4-4.2" class="pilcrow"></a>
</li>
</ul>
</section>
</div>
<div id="encoding">
<section id="section-5">
<h2 id="name-mapping-to-ccnx-and-ndn-pac">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-mapping-to-ccnx-and-ndn-pac" class="section-name selfRef">Mapping to CCNx and NDN packet encodings</a>
</h2>
<p id="section-5-1">The only actual protocol needed is a TLV in Interest messages that states the size in bytes of the expected Data Message coming back, and in the Interest Return on a "too big" error to carry the actual data size. In the case of CCNx, this covers the encapsulated Data Object, but not the hop-by-hop headers.<a href="#section-5-1" class="pilcrow"></a></p>
<div id="CCNx-encoding">
<section id="section-5.1">
<h3 id="name-packet-encoding-for-ccnx">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-packet-encoding-for-ccnx" class="section-name selfRef">Packet encoding for CCNx</a>
</h3>
<p id="section-5.1-1">For CCNx<span>[<a href="#RFC8569" class="xref">RFC8569</a>]</span> there is a new hop-by-hop header TLV, and a new value of the Interest Return "Return Type".<a href="#section-5.1-1" class="pilcrow"></a></p>
<p id="section-5.1-2">Expected Data Size (for Interest messages), or Actual Data Size (for Interest Return messages) TLV<a href="#section-5.1-2" class="pilcrow"></a></p>
<span id="name-data-size-tlv"></span><div id="DataSize">
<table class="center" id="table-1">
<caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-data-size-tlv" class="selfRef">Data Size TLV</a>
</caption>
<thead>
<tr>
<th class="text-center" rowspan="1" colspan="1">Abbrev</th>
<th class="text-center" rowspan="1" colspan="1">Name</th>
<th class="text-center" rowspan="1" colspan="1">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td class="text-center" rowspan="1" colspan="1">T_DATASIZE</td>
<td class="text-center" rowspan="1" colspan="1">Data Size</td>
<td class="text-center" rowspan="1" colspan="1">Expected (<a href="#description" class="xref">Section 3</a>) or Actual (<a href="#toobig" class="xref">Section 3.2</a>) Data Size</td>
</tr>
</tbody>
</table>
</div>
</section>
</div>
<div id="NDN-encoding">
<section id="section-5.2">
<h3 id="name-packet-encoding-for-ndn">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-packet-encoding-for-ndn" class="section-name selfRef">Packet encoding for NDN</a>
</h3>
<p id="section-5.2-1">TBD based on <span>[<a href="#NDNTLV" class="xref">NDNTLV</a>]</span>. Suggestions from the NDN team greatly appreciated.<a href="#section-5.2-1" class="pilcrow"></a></p>
</section>
</div>
</section>
</div>
<div id="IANA">
<section id="section-6">
<h2 id="name-iana-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
</h2>
<p id="section-6-1">Please Add the T_DATASIZE TLV to the Hop-by-Hop TLV types registry of RFC8609, with fixed length of 2, and data type numeric<a href="#section-6-1" class="pilcrow"></a></p>
<p id="section-6-2">Expected/Actual Data Size TLV encoding. The range has an upper bound of 64K bytes, since that is the largest MTU supported by CCNx.<a href="#section-6-2" class="pilcrow"></a></p>
<span id="name-expected-actual-datazize-us"></span><div id="datasize-encoding">
<figure id="figure-1">
<div class="artwork art-text alignLeft" id="section-6-3.1">
<pre>
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_DATASIZE | 2 |
+---------------+---------------+---------------+---------------+
| Expected/Actual Data Size |
+---------------+---------------+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-expected-actual-datazize-us" class="selfRef">Expected/Actual Datazize using RFC8609 encoding</a>
</figcaption></figure>
</div>
</section>
</div>
<div id="Security">
<section id="section-7">
<h2 id="name-security-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
</h2>
<p id="section-7-1"><a href="#malicious" class="xref">Section 4</a> addresses the major security considerations for this specification.<a href="#section-7-1" class="pilcrow"></a></p>
</section>
</div>
<div id="Acknowledgements">
<section id="section-8">
<h2 id="name-acknowledgements">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
</h2>
<p id="section-8-1">Klaus Schneider and Ken Calvert have contributed a number of useful comments which have substantially improved the document.<a href="#section-8-1" class="pilcrow"></a></p>
</section>
</div>
<section id="section-9">
<h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
</h2>
<section id="section-9.1">
<h3 id="name-normative-references">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
</h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
<dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8569">[RFC8569]</dt>
<dd>
<span class="refAuthor">Mosko, M.</span><span class="refAuthor">, Solis, I.</span><span class="refAuthor">, and C. Wood</span>, <span class="refTitle">"Content-Centric Networking (CCNx) Semantics"</span>, <span class="seriesInfo">RFC 8569</span>, <span class="seriesInfo">DOI 10.17487/RFC8569</span>, <time datetime="2019-07" class="refDate">July 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8569">https://www.rfc-editor.org/info/rfc8569</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8609">[RFC8609]</dt>
<dd>
<span class="refAuthor">Mosko, M.</span><span class="refAuthor">, Solis, I.</span><span class="refAuthor">, and C. Wood</span>, <span class="refTitle">"Content-Centric Networking (CCNx) Messages in TLV Format"</span>, <span class="seriesInfo">RFC 8609</span>, <span class="seriesInfo">DOI 10.17487/RFC8609</span>, <time datetime="2019-07" class="refDate">July 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8609">https://www.rfc-editor.org/info/rfc8609</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-9.2">
<h3 id="name-informative-references">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
</h3>
<dl class="references">
<dt id="Carofiglio2012">[Carofiglio2012]</dt>
<dd>
<span class="refAuthor">Carofiglio, G.</span><span class="refAuthor">, Gallo, M.</span><span class="refAuthor">, and L. Muscariello</span>, <span class="refTitle">"Joint hop-by-hop and receiver-driven interest control protocol for content-centric networks, in ICN Workshop at SIGcomm 2012"</span>, <span class="seriesInfo">DOI 10.1145/2377677.2377772</span>, <time datetime="2102" class="refDate">2102</time>, <span>&lt;<a href="http://conferences.sigcomm.org/sigcomm/2012/paper/icn/p37.pdf">http://conferences.sigcomm.org/sigcomm/2012/paper/icn/p37.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="DASH">[DASH]</dt>
<dd>
<span class="refTitle">"Dynamic Adaptive Streaming over HTTP"</span>, <span>various</span>, <span>&lt;<a href="https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP">https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Ghali2013">[Ghali2013]</dt>
<dd>
<span class="refAuthor">Ghali, C.</span><span class="refAuthor">, Narayanan, A.</span><span class="refAuthor">, Oran, D.</span><span class="refAuthor">, Tsudik, G.</span><span class="refAuthor">, and C. Wood</span>, <span class="refTitle">"Secure Fragmentation for Content-Centric Networks, in IEEE 14th International Symposium on Network Computing and Applications"</span>, <span class="seriesInfo">DOI 10.1109/nca.2015.34</span>, <time datetime="2015" class="refDate">2015</time>, <span>&lt;<a href="http://dx.doi.org/10.1109/NCA.2015.34">http://dx.doi.org/10.1109/NCA.2015.34</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-quic-transport">[I-D.ietf-quic-transport]</dt>
<dd>
<span class="refAuthor">Iyengar, J.</span><span class="refAuthor"> and M. Thomson</span>, <span class="refTitle">"QUIC: A UDP-Based Multiplexed and Secure Transport"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-transport-27</span>, <time datetime="2020-02-21" class="refDate">21 February 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-quic-transport-27">https://tools.ietf.org/html/draft-ietf-quic-transport-27</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.irtf-icnrg-flic">[I-D.irtf-icnrg-flic]</dt>
<dd>
<span class="refAuthor">Tschudin, C.</span><span class="refAuthor">, Wood, C.</span><span class="refAuthor">, Mosko, M.</span><span class="refAuthor">, and D. Oran</span>, <span class="refTitle">"File-Like ICN Collections (FLIC)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-irtf-icnrg-flic-02</span>, <time datetime="2019-11-04" class="refDate">4 November 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-irtf-icnrg-flic-02">https://tools.ietf.org/html/draft-irtf-icnrg-flic-02</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Mahdian2016">[Mahdian2016]</dt>
<dd>
<span class="refAuthor">Mahdian, M.</span><span class="refAuthor">, Arianfar, S.</span><span class="refAuthor">, Gibson, J.</span><span class="refAuthor">, and D. Oran</span>, <span class="refTitle">"MIRCC: Multipath-aware ICN Rate-based Congestion Control, in Proceedings of the 3rd ACM Conference on Information-Centric Networking"</span>, <span class="seriesInfo">DOI 10.1145/2984356.2984365</span>, <time datetime="2016" class="refDate">2016</time>, <span>&lt;<a href="http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p1-mahdian.pdf">http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p1-mahdian.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="minmaxfairness">[minmaxfairness]</dt>
<dd>
<span class="refTitle">"Max-min Fairness"</span>, <span>various</span>, <span>&lt;<a href="https://en.wikipedia.org/wiki/Max-min_fairness">https://en.wikipedia.org/wiki/Max-min_fairness</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="NDN">[NDN]</dt>
<dd>
<span class="refTitle">"Named Data Networking"</span>, <span>various</span>, <span>&lt;<a href="https://named-data.net/project/execsummary/">https://named-data.net/project/execsummary/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="NDNTLV">[NDNTLV]</dt>
<dd>
<span class="refTitle">"NDN Packet Format Specification."</span>, <time datetime="2016" class="refDate">2016</time>, <span>&lt;<a href="http://named-data.net/doc/ndn-tlv/">http://named-data.net/doc/ndn-tlv/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="proportionalfairness">[proportionalfairness]</dt>
<dd>
<span class="refTitle">"Proportionally Fair"</span>, <span>various</span>, <span>&lt;<a href="https://en.wikipedia.org/wiki/Proportionally_fair">https://en.wikipedia.org/wiki/Proportionally_fair</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0793">[RFC0793]</dt>
<dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Transmission Control Protocol"</span>, <span class="seriesInfo">STD 7</span>, <span class="seriesInfo">RFC 793</span>, <span class="seriesInfo">DOI 10.17487/RFC0793</span>, <time datetime="1981-09" class="refDate">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc793">https://www.rfc-editor.org/info/rfc793</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4340">[RFC4340]</dt>
<dd>
<span class="refAuthor">Kohler, E.</span><span class="refAuthor">, Handley, M.</span><span class="refAuthor">, and S. Floyd</span>, <span class="refTitle">"Datagram Congestion Control Protocol (DCCP)"</span>, <span class="seriesInfo">RFC 4340</span>, <span class="seriesInfo">DOI 10.17487/RFC4340</span>, <time datetime="2006-03" class="refDate">March 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4340">https://www.rfc-editor.org/info/rfc4340</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4960">[RFC4960]</dt>
<dd>
<span class="refAuthor">Stewart, R., Ed.</span>, <span class="refTitle">"Stream Control Transmission Protocol"</span>, <span class="seriesInfo">RFC 4960</span>, <span class="seriesInfo">DOI 10.17487/RFC4960</span>, <time datetime="2007-09" class="refDate">September 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4960">https://www.rfc-editor.org/info/rfc4960</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Schneider2016">[Schneider2016]</dt>
<dd>
<span class="refAuthor">Schneider, K.</span><span class="refAuthor">, Yi, C.</span><span class="refAuthor">, Zhang, B.</span><span class="refAuthor">, and L. Zhang</span>, <span class="refTitle">"A Practical Congestion Control Scheme for Named Data Networking, in Proceedings of the 2016 conference on 3rd ACM Conference on Information-Centric Networking - ACM-ICN '16"</span>, <span class="seriesInfo">DOI 10.1145/2984356.2984369</span>, <time datetime="2016" class="refDate">2016</time>, <span>&lt;<a href="http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p21-schneider.pdf">http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p21-schneider.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Song2018">[Song2018]</dt>
<dd>
<span class="refAuthor">Song, J.</span><span class="refAuthor">, Lee, M.</span><span class="refAuthor">, and T. Kwon</span>, <span class="refTitle">"SMIC: Subflow-level Multi-path Interest Control for Information Centric Networking, in 5th ACM Conference on Information-Centric Networking"</span>, <span class="seriesInfo">DOI 10.1145/3267955.3267971</span>, <time datetime="2018" class="refDate">2018</time>, <span>&lt;<a href="https://conferences.sigcomm.org/acm-icn/2018/proceedings/icn18-final62.pdf">https://conferences.sigcomm.org/acm-icn/2018/proceedings/icn18-final62.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Wang2013">[Wang2013]</dt>
<dd>
<span class="refAuthor">Wang, Y.</span><span class="refAuthor">, Rozhnova, N.</span><span class="refAuthor">, Narayanan, A.</span><span class="refAuthor">, Oran, D.</span><span class="refAuthor">, and I. Rhee</span>, <span class="refTitle">"An Improved Hop-by-hop Interest Shaper for Congestion Control in Named Data Networking, in ACM SIGCOMM Workshop on Information-Centric Networking"</span>, <span class="seriesInfo">DOI 10.1145/2534169.2491233</span>, <time datetime="2013" class="refDate">2013</time>, <span>&lt;<a href="http://conferences.sigcomm.org/sigcomm/2013/papers/icn/p55.pdf">http://conferences.sigcomm.org/sigcomm/2013/papers/icn/p55.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="authors-addresses">
<section id="section-appendix.a">
<h2 id="name-authors-address">
<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
</h2>
<address class="vcard">
<div dir="auto" class="left"><span class="fn nameRole">Dave Oran</span></div>
<div dir="auto" class="left"><span class="org">Network Systems Research and Design</span></div>
<div dir="auto" class="left"><span class="street-address">4 Shady Hill Square</span></div>
<div dir="auto" class="left">
<span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02138</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:daveoran@orandom.net" class="email">daveoran@orandom.net</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
toc.classList.remove("active");
});
</script>
</body>
</html>