1 - 2 - 6 - 8 - A - B - C - D - E - F - G - H - I - K - L - M - N - O - P - Q - R - S - T - U - V - W - X
router
Click on the red underlined text to get to the source
... connection [RFC3390]. Our underlying premise is that
explicit feedback from all the routers along the path would be
required, in the current architecture, for best-effort connections ...
... in the IP header of a TCP packet. Each router along the path could,
in turn, either approve the requested rate, reduce the requested
rate, or indicate that the Quick-Start Request ...
... rate, or indicate that the Quick-Start Request is not approved. (We
note that the `routers' referred to in this document also include the
IP-layer processing of the Quick-Start Request ...
... sender.) In
approving a Quick-Start Request, a router does not give preferential
treatment to subsequent packets from that connection; the router ...
... router does not give preferential
treatment to subsequent packets from that connection; the router is
only asserting that it is currently underutilized and believes there
is sufficient available bandwidth ...
... requested rate. The Quick-Start mechanism can determine if there are
routers along the path that do not understand the Quick-Start Option,
or have not agreed to the Quick-Start ...
... Quick-Start would not be the first mechanism for explicit
communication from routers to transport protocols about sending
rates. Explicit Congestion Notification ...
... ECN) gives explicit
congestion control feedback from routers to transport protocols,
based on the router ...
... routers to transport protocols,
based on the router detecting congestion before buffer overflow
...
... buffer overflow
[RFC3168]. In contrast, routers would not use Quick-Start to give
congestion ...
... optional mechanism to give permission to transport protocols to use
higher sending rates, based on the ability of all the routers along
the path to determine if their respective output links are
...
... Quick-Start in transport end-nodes and routers.
Section 9 gives an evaluation of the costs and benefits of Quick-
Start ...
... The appendices discuss related work, Quick-Start design decisions,
and possible router algorithms.
...
... connection traverses
different queues, and possibly even different routers. Thus, any
mechanism for determining the allowed sending rate would have to be
...
...
* Any new mechanism must be incrementally deployable and might not be
supported by all the routers and/or end-hosts. Thus, any new
mechanism must be able to accommodate non-supporting routers ...
... routers and/or end-hosts. Thus, any new
mechanism must be able to accommodate non-supporting routers or
end-hosts without disturbing the current Internet ...
... connection unless both end-nodes and all the routers along the path
have been configured to support Quick-Start.
...
...
* Our underlying premise is that explicit feedback from all the
routers along the path would be required, in the current
architecture, for best-effort connections ...
... absence of other information about the path.
* A router should only approve a Quick-Start Request if the output
link ...
... per-flow state at the router, or the possibility of a (possibly
transient) queue at the router ...
... per-flow state is not required, we also do not preclude a
router from storing per-flow state for making Quick-Start ...
... Quick-Start requires end-points and routers to work together, with
end-points requesting a higher sending rate ...
... QS)
option in IP, and routers along the path approving, modifying,
discarding, or ignoring (and therefore disallowing) the Quick-Start
Request. The receiver ...
... Quick-Start Time to Live (QS
TTL) to be decremented by every router along the path that
understands the option and approves the request. The Quick-Start TTL ...
... sender uses the TTL difference to determine if
all the routers along the path decremented the Quick-Start TTL,
...
... Quick-Start Request.
If the request is approved by all the routers along the path, then
the TCP sender ...
... Quick-Start, with the sender's IP
layer and both routers along the path approving the Quick-Start
Request, and the TCP receiver ...
... Figure 2 shows an unsuccessful use of Quick-Start, with one of the
routers along the path not approving the Quick-Start Request. If the
Quick-Start Request ...
... QS TTL field to a random value.
Routers that approve the Quick-Start Request decrement the QS TTL
...
... (mod 256) by the same amount that they decrement the IP TTL. (As
elsewhere in this document, we use the term `router' imprecisely to
also include the Quick-Start functionality at the IP layer ...
... QS TTL is used by the sender to detect if all the
routers along the path understood and approved the Quick-Start
option.
...
... sender SHOULD set the
reserved field to zero, and routers and receivers SHOULD ignore the
reserved field ...
... Table 1: Mapping from Rate Request Field to Rate Request in Kbps.
Routers can approve the Quick-Start Request for a lower rate by
decreasing the Rate Request in the Quick-Start Request ...
... Start Request was denied, and set a Report of Approved Rate with a
rate of zero. Routers may choose to ignore the Report of Approved
Rate, or to use the Report of Approved Rate but ignore the QS Nonce.
...
... Rate, or to use the Report of Approved Rate but ignore the QS Nonce.
Alternately, some routers that use the Report of Approved Rate may
choose to match the QS Nonce, masked by the approved rate, with the
...
... The use of the Quick-Start Option does not require the additional use
of the Router Alert Option [RFC2113].
...
... We note that in IPv4, a change in IP options at routers requires
recalculating the IP header checksum ...
... Processing the Quick-Start Request at Routers ...
... sending rate of
the connection sending the request; in the default case of a router
(or IP-layer implementation at an end-node ...
... per-flow state, a router makes the conservative assumption that the
flow's current sending rate ...
... flow's current sending rate is zero. Each participating router can
either terminate or approve the Quick-Start Request. A router ...
... router can
either terminate or approve the Quick-Start Request. A router MUST
only approve a Quick-Start Request if the output link ...
... Quick-Start Request if the output link is
underutilized, and if the router judges that the output link will
continue to be underutilized if this and earlier approved requests
...
... continue to be underutilized if this and earlier approved requests
are used by the senders. Otherwise, the router reduces or terminates
the Quick-Start Request.
...
... Quick-Start Request, this document does not specify the specific
algorithms to be used by routers in processing Quick-Start Requests
or Reports. This is similar to RFC 3168prop ...
... IP header, but does not
specify specific algorithms for routers to use in deciding when to
drop or mark packets before buffer overflow.
...
... buffer overflow.
A router that wishes to terminate the Quick-Start Request SHOULD
either delete ...
... QS Nonce, and Rate Request fields. Deleting the Quick-Start
Request saves resources because downstream routers will have no
option to process, but zeroing the Rate Request field may be more
efficient for routers ...
... routers will have no
option to process, but zeroing the Rate Request field may be more
efficient for routers to implement. As suggested in [B05], future
additions to Quick-Start ...
... additions to Quick-Start could define error codes for routers to
insert into the QS Nonce field to report back to the sender ...
... sender the
reason that the Quick-Start Request was denied, e.g., that the router
is denying all Quick-Start Requests at this time, or that this
...
... is denying all Quick-Start Requests at this time, or that this
router, as a matter of policy, does not grant Quick-Start requests.
A router ...
... router, as a matter of policy, does not grant Quick-Start requests.
A router that doesn't understand the Quick-Start Option will simply
forward the packet with the Quick-Start Request ...
... Quick-Start will not be used).
If the participating router has decided to approve the Quick-Start
Request, it does the following:
...
... Quick-Start
Request, it does the following:
* The router MUST decrement the QS TTL by the amount the IP TTL is
...
... decremented (usually one).
* If the router is only willing to approve a Rate Request less than
that in the Quick-Start Request, then the router ...
... router is only willing to approve a Rate Request less than
that in the Quick-Start Request, then the router replaces the Rate
Request with a smaller value. The router MUST NOT increase the
...
... Quick-Start Request, then the router replaces the Rate
Request with a smaller value. The router MUST NOT increase the
Rate Request in the Quick-Start Request. If the router ...
... router MUST NOT increase the
Rate Request in the Quick-Start Request. If the router decreases
the Rate Request, the router ...
... router decreases
the Rate Request, the router MUST also modify the QS Nonce, as
described in Section 3.4.
...
... checksum.
If the router approves the Quick-Start Request, this approval SHOULD
be taken into account in the router ...
... router approves the Quick-Start Request, this approval SHOULD
be taken into account in the router's decision to accept or reject
subsequent Quick-Start Requests (e.g., using a variable that tracks
...
... consideration of earlier approved Quick-Start Requests is necessary
to ensure that the router only approves a Quick-Start Request when
the router ...
... router only approves a Quick-Start Request when
the router judges that the output link will remain underutilized if
this and earlier Quick-Start Requests ...
... In addition, the approval of a Quick-Start Request SHOULD NOT be used
by the router to affect the treatment of the data packets that arrive
from this connection ...
... connection in the next few round-trip times. That is, the
approval by the router of a Quick-Start Request does not give
differential treatment for Quick-Start ...
... differential treatment for Quick-Start data packets at that router;
it is only a statement from the router that the router ...
... data packets at that router;
it is only a statement from the router that the router believes that
the subsequent Quick-Start ...
... router;
it is only a statement from the router that the router believes that
the subsequent Quick-Start data packets ...
... connection will not
change the current underutilized state of the router.
A non-participating router ...
... router.
A non-participating router forwards the Quick-Start Request
unchanged, without decrementing the QS TTL ...
... unchanged, without decrementing the QS TTL. The non-participating
router still decrements the TTL field in the IP header, as is
...
... TTL field in the IP header, as is
required for all routers [RFC1812]. As a result, the sender will be
...
... able to detect that the Quick-Start Request had not been understood
or approved by all of the routers along the path.
A router ...
... routers along the path.
A router that uses multipath routing for packets within a single
connection MUST NOT approve a Quick-Start Request ...
... Quick-Start Option has the Function field set to "1000", then
this is a Report of Approved Rate, rather than a Rate Request. The
router MAY ignore such an option, and, in any case, it MUST NOT
modify the contents of the option for a Report of Approved Rate.
However, the router ...
... router MAY ignore such an option, and, in any case, it MUST NOT
modify the contents of the option for a Report of Approved Rate.
However, the router MAY use the Approved Rate report to check that
the sender is not lying about the approved rate. If the reported
...
... the sender is not lying about the approved rate. If the reported
Approved Rate is higher than the rate that the router actually
approved for this connection in the previous round-trip time ...
... connection in the previous round-trip time, then
the router may implement some policy for cheaters. For instance, the
router MAY decide to deny future Quick-Start Requests ...
... the router may implement some policy for cheaters. For instance, the
router MAY decide to deny future Quick-Start Requests from this
sender ...
...
senders in more detail. From the Report of Approved Rate, the router
can also learn if some of the downstream routers ...
... router
can also learn if some of the downstream routers have approved the
Quick-Start Request for a smaller rate or denied the use of Quick-
...
... QS Nonce to a random value.
If the router reduces the Rate Request from rate K to rate K-1, then
the router MUST set the field in the QS Nonce ...
... If the router reduces the Rate Request from rate K to rate K-1, then
the router MUST set the field in the QS Nonce for "Rate K -> Rate
K-1" to a new random value ...
... QS Nonce for "Rate K -> Rate
K-1" to a new random value. Similarly, if the router reduces the
Rate Request by N steps, the router MUST set the 2N bits ...
... random value. Similarly, if the router reduces the
Rate Request by N steps, the router MUST set the 2N bits in the
relevant fields in the QS Nonce ...
... We note that the protection offered by the QS Nonce is the same
whether one router makes all the decrements in the rate request, or
whether they are made at different routers along the path.
...
... whether one router makes all the decrements in the rate request, or
whether they are made at different routers along the path.
The requirements ...
... The requirements for randomization for the sender and routers in
setting `random' values in the QS Nonce are not stringent -- almost
...
... bits of the QS Nonce are
changed by a router along the path, the receiver should not be able
to guess those two bits ...
... QS Nonce were
generated by the sender, and which were generated by routers along
the path. This makes it harder for the receiver to infer the value
...
... round-trip-time estimate might be longer than for succeeding
round-trip times, e.g., because of delays at routers processing the
IP Quick-Start Option ...
... Quick-Start Request Packets that are Discarded by Routers or ...
... network due to congestion, or to be
blocked due to interactions with routers or middleboxes, where a
middlebox is defined as any intermediary box performing functions
...
... middlebox is defined as any intermediary box performing functions
apart from normal, standard functions of an IP router on the data
path between a source host and destination host ...
... IP
TimeStamp Option). In both cases, this is presumably due to routers
or middleboxes along that path.
...
... TCP SYN packet could be due to congestion, a
router or middlebox dropping the packet because of the IP Option, or
...
... middlebox dropping the packet because of the IP Option, or
a router or middlebox dropping the packet because of the information
in the TCP header ...
... tunnel configured to support ECN,
where the egress router might copy the ECN codepoint in the outer
...
... sender incorrectly believes that the Quick-Start Request was
approved by all routers along the path. If the use of Quick-Start
over the tunnel ...
... sender incorrectly
believes that the Quick-Start Request was approved by all routers
along the path. This is discussed in Section 6.2 below.
...
... IP tunnel `supports
Quick-Start' if it allows routers along the tunnel path to process
the Quick-Start Request ...
... If the tunnel ingress for the simple tunnel is at a router, the IP
TTL of the inner header is generally decremented during forwarding
...
... Quick-Start Request is
not copied to the outer header, saving the routers within the tunnel
from unnecessarily processing the Quick-Start Request ...
... If the tunnel ingress is at a sending host or router where the IP TTL
is not decremented prior to encapsulation ...
... is independent of the TCP sender or a router implementation that
supports Quick-Start. In these cases, it is possible that a Quick-
...
... Quick-Start. In these cases, it is possible that a Quick-
Start Request gets erroneously approved without the routers in the
tunnel having individually approved the request, causing a false
...
... sender incorrectly believes
that the Quick-Start Request was approved by all routers along the
path.
...
... Deciding the Permitted Rate Request at a Router ...
...
In this section, we briefly outline how a router might decide whether
or not to approve a Quick-Start Request. The router ...
... router might decide whether
or not to approve a Quick-Start Request. The router should ask the
following questions:
...
... following questions:
* Has the router's output link been underutilized for some time
(e.g., several seconds)?
...
... * Would the output link remain underutilized if the arrival rate were
to increase by the aggregate rate requests that the router has
approved over the last fraction of a second?
...
... approved over the last fraction of a second?
In order to answer the last question, the router must have some
knowledge of the available bandwidth on the output link ...
... bandwidth that could arrive due to recently approved
Quick-Start Requests. In this way, if an underutilized router
experiences a flood of Quick-Start Requests ...
... experiences a flood of Quick-Start Requests, the router can begin to
deny Quick-Start Requests while the output link ...
... underutilized.
A simple way for the router to keep track of the potential bandwidth
from recently approved requests is to maintain two counters ...
... Requests approved over a previous time interval [T0,T1]. However,
this document doesn't specify router algorithms for approving Quick-
Start ...
... Quick-Start
bandwidth. A possible router algorithm is given in Appendix E, and
more discussion of these issues is available in [SAF06 ...
... SAF06].
* If the router's output link has been underutilized and the
aggregate of the Quick-Start Request ...
... Quick-Start Request Rate options granted is low
enough to prevent a near-term bandwidth shortage, then the router
could approve the Quick-Start Request.
...
... Section 10.2 discusses some of the implementation issues in
processing Quick-Start Requests at routers. [SAF06] discusses the
range ...
... range of possible Quick-Start algorithms at the router for deciding
whether to approve a Quick-Start Request. In order to explore the
...
... whether to approve a Quick-Start Request. In order to explore the
limits of the possible functionality at routers, [SAF06] also
discusses Extreme Quick-Start ...
... SAF06] also
discusses Extreme Quick-Start mechanisms at routers, where the router
would keep per-flow ...
... discusses Extreme Quick-Start mechanisms at routers, where the router
would keep per-flow state ...
... Quick-Start for the connection
and for the routers along the path.
The cost of having a Quick-Start Request ...
... Quick-Start data packets. This should be an unlikely situation
because routers are expected to approve Quick-Start Requests only
when they are significantly underutilized. However, a transient
...
... when they are significantly underutilized. However, a transient
increase in cross-traffic in one of the routers, a sudden decrease in
available bandwidth on one of the links ...
... packet losses even when the Quick-Start Request
was approved by all of the routers along the path. If a Quick-Start
packet is dropped, then the sender ...
... Quick-Start packet dropped can be considerable.)
Added complexity at routers:
The main cost of Quick-Start at routers ...
... routers:
The main cost of Quick-Start at routers concerns the costs of added
complexity. The added complexity at the end-points is moderate, and
...
... Quick-Start to the end
hosts. The added complexity at the routers is also somewhat
moderate; it involves estimating the unused bandwidth on the output
...
... Quick-Start rate
approved over the last fraction of a second. However, this added
complexity at routers adds to the development cycle, and could
prevent the addition of other competing functionality to routers ...
... routers adds to the development cycle, and could
prevent the addition of other competing functionality to routers.
Thus, careful thought would have to be given to the addition of
Quick-Start ...
... IP.
The slow path in routers:
Another drawback of Quick-Start is that packets containing the
...
... Quick-Start is that packets containing the
Quick-Start Request message might not take the fast path in routers,
particularly in the beginning of Quick-Start's deployment ...
... Internet. This would mean some extra delay for the end hosts, and
extra processing burden for the routers. However, as discussed in
Sections 4.1 and 4.7, not all packets would carry the Quick-Start
option. In addition, for the underutilized links ...
... flows, the burden of the Quick-
Start Option on routers would be considerably reduced. Nevertheless,
it is still conceivable, in the worst case, that many packets would
carry Quick-Start Requests ...
... Quick-Start Requests; this could slow down the processing of
Quick-Start packets in routers considerably. As discussed in Section
9.6, routers can easily protect against this by enforcing a limit on
...
... Quick-Start packets in routers considerably. As discussed in Section
9.6, routers can easily protect against this by enforcing a limit on
the rate at which Quick-Start Requests will be considered. [RW03 ...
... rate.
As specified in Section 3.3, a router that uses multipath routing for
packets within a single connection ...
... Non-IP queues:
A problem of any mechanism for feedback from routers at the IP level
is that there can be queues ...
... end-to-end path
that are not in IP-level routers. As an example, these include
queues in layer ...
... networks. One possibility would
be that an IP-level router adjacent to such a non-IP queue or
...
... configured so that non-IP queues between IP routers do not end up
being the congested bottlenecks.
...
... traffic using some form of differentiated services, and
routers could take the traffic class into account when deciding
whether or not to grant the Quick-Start Request ...
... Quick-Start.
Routers are also free to take into account their own priority
classifications in processing Quick-Start Requests ...
... senders,
receivers, or colluding routers or middleboxes lying about the
Quick-Start Request.
...
... Report of Approved Rate.
If a router or receiver receives an Approved Rate report that is
larger than the Rate Request in the Quick-Start Request ...
... connection in the previous round-trip time, then
the router or receiver could deny future Quick-Start Requests from
...
... Quick-Start Request from future
packets from that sender. We note that routers are not required to
use Approved Rate reports to check if senders are cheating; this is
...
... use Approved Rate reports to check if senders are cheating; this is
at the discretion of the router.
If a router ...
... router.
If a router sees a Report of Approved Rate, and did not see an
earlier Quick-Start Request, then either the sender ...
... connection's path could have changed since the
Quick-Start Request was sent. In either case, the router could
decide to deny future Quick-Start Requests for this connection ...
... Quick-Start Requests for this connection. In
particular, it is reasonable for the router to deny a Quick-Start
request if either the sender is cheating, or if the connection ...
... suffers from path changes or multipathing.
If a router approved a Quick-Start Request, but does not see a
subsequent Approved Rate report, then there are several
...
... network; or (4) the Approved Rate report took a different path from
the Quick-Start Request. In any of these cases, the router would be
justified in denying future Quick-Start Requests for this connection ...
... reporting the TTL Diff and QS Nonce. If a router that understands
the Quick-Start Request denies the request by deleting the request or
...
... Quick-Start Request is denied only by a non-Quick-
Start-capable router, or by a router that is unable to zero the QS
TTL and QS Nonce ...
... Start-capable router, or by a router that is unable to zero the QS
TTL and QS Nonce fields, then the receiver ...
... Quick-Start Requests.
Unfortunately, if a router doesn't understand Quick-Start, then it is
not possible for that router ...
... router doesn't understand Quick-Start, then it is
not possible for that router to take an active step such as zeroing
the QS TTL ...
... receivers in the
case of non-Quick-Start-capable routers.
What would be the incentives for a receiver ...
... Quick-Start Request with a Rate Request of Y > X, then the sender
knows that either some router along the path malfunctioned
(increasing the Rate Request inappropriately), or the receiver is
...
... receivers lying about the value of the Rate Request. One possible
additional protection would be for a router that decreases a Rate
Request in a Quick-Start Request to report the decrease directly to
...
... Collusion between Misbehaving Routers ...
... In addition to protecting against misbehaving receivers, it is
necessary to protect against misbehaving routers. Consider collusion
between an ingress router and an egress router ...
... necessary to protect against misbehaving routers. Consider collusion
between an ingress router and an egress router belonging to the same
intranet ...
... routers. Consider collusion
between an ingress router and an egress router belonging to the same
intranet. The ingress router ...
... router belonging to the same
intranet. The ingress router could decrement the Rate Request at the
ingress, with the egress router increasing it again at the egress.
...
... intranet. The ingress router could decrement the Rate Request at the
ingress, with the egress router increasing it again at the egress.
The routers between the ingress and egress that approved the
...
... ingress, with the egress router increasing it again at the egress.
The routers between the ingress and egress that approved the
decremented rate request might not have been willing to approve the
...
... larger, original request.
Another form of collusion would be for the ingress router to inform
the egress router out-of-band ...
... Another form of collusion would be for the ingress router to inform
the egress router out-of-band of the TTL Diff and QS Nonce ...
... TTL Diff and QS Nonce for the
request packet at the ingress. This would enable the egress router
to modify the QS TTL and QS Nonce ...
... QS TTL and QS Nonce so that it appeared that all the
routers along the path had approved the request. There does not
appear to be any protection against a colluding ingress and egress
...
... appear to be any protection against a colluding ingress and egress
router. Even if an intermediate router had deleted the Quick-Start
Option ...
... protection against a colluding ingress and egress
router. Even if an intermediate router had deleted the Quick-Start
Option from the packet, the ingress router ...
... router had deleted the Quick-Start
Option from the packet, the ingress router could have sent the
Quick-Start Option to the egress router ...
... router could have sent the
Quick-Start Option to the egress router out-of-band, with the egress
router ...
... router out-of-band, with the egress
router inserting the Quick-Start Option, with a modified QS TTL
...
... However, unlike ECN, there is somewhat less of an incentive for
cooperating ingress and egress routers to collude to falsely modify
the Quick-Start Request so that it appears to have been approved by
...
... the Quick-Start Request so that it appears to have been approved by
all the routers along the path. With ECN, a colluding ingress router
...
... all the routers along the path. With ECN, a colluding ingress router
could falsely mark a packet as ECN-capable, with the colluding egress
...
... could falsely mark a packet as ECN-capable, with the colluding egress
router returning the ECN field in the IP header to its original non-
...
... ECN-capable codepoint, and congested routers along the path could
have been fooled into not dropping that packet. This collusion would
give an unfair competitive advantage to the traffic ...
... give an unfair competitive advantage to the traffic protected by the
colluding ingress and egress routers.
In contrast, with Quick-Start ...
... In contrast, with Quick-Start, the collusion of the ingress and
egress routers to make it falsely appear that a Quick-Start Request
was approved sometimes would give an advantage to the traffic ...
... traffic covered
by that collusion, and sometimes would give a disadvantage, depending
on the details of the scenario. If some router along the path really
does not have enough available bandwidth to approve the Quick-Start
Request ...
... disadvantage of the connection. Thus, while the ingress and egress
routers could collude to prevent intermediate routers from denying a
Quick-Start Request ...
... connection. Thus, while the ingress and egress
routers could collude to prevent intermediate routers from denying a
Quick-Start Request, it would not always be to the connection ...
... advantage for this to happen. One defense against such a collusion
would be for some router between the ingress and egress nodes that
denied the request to monitor connection ...
... Quick-Start after a Quick-Start
Request was denied, or that are reporting an Approved Rate higher
than that actually approved by that router.
If the congested router ...
... router.
If the congested router is ECN-capable, and the colluding ingress and
egress routers ...
... router is ECN-capable, and the colluding ingress and
egress routers are lying about ECN-capability as well as about
Quick-Start ...
...
Start packets falsely appear to the congested router to be ECN-
capable. In this case, the colluding routers ...
... router to be ECN-
capable. In this case, the colluding routers might succeed in giving
a competitive advantage to the traffic protected by their collusion
...
... a competitive advantage to the traffic protected by their collusion
(if no intermediate router is monitoring to catch such misbehavior).
...
... by the same amount, then the sender's mechanism for determining if
the request was approved by all routers along the path would no
longer be reliable. Rewriting the IP TTL could result in false
...
... tie up available Quick-Start bandwidth, preventing routers from
approving Quick-Start Requests from other connections ...
... approving Quick-Start Requests from other connections. Routers can
protect against the first kind of attack by applying a simple limit
...
... on the rate at which Quick-Start Requests will be considered by the
router.
The second kind of attack ...
... because they are from malicious attackers or because they are denied
by routers downstream, can result in short-term `wasting' of
potential Quick-Start ...
... potential Quick-Start bandwidth, resulting in routers denying
subsequent Quick-Start Requests that, if approved, would in fact have
...
... Quick-Start for the connection, the relative
benefits of different router-based algorithms for approving Quick-
Start ...
... deployment
issues, such as the chicken-and-egg deployment problems of mechanisms
that have to be deployed in both routers and end nodes in order to
work, and the problems posed by the wide deployment ...
... Quick-Start should not be
enabled by default in end-nodes or in routers; instead, when Quick-
Start is used, it should be explicitly enabled by users or system
administrators ...
... might consider an initial deployment of Quick-Start in the routers
and end-nodes, where the incentives for routers ...
... routers
and end-nodes, where the incentives for routers to deploy Quick-
Start might be the most clear.
...
... deployment of Quick-
Start in routers. For example, Quick-Start could be quite useful
in high-bandwidth ...
... unlike ECN, which can be of benefit even if it is only deployed on
one of the routers along the end-to-end path, a connection's use of
...
... Quick-Start requires Quick-Start deployment on all of the routers
along the end-to-end path. Second, unlike ECN ...
... senders or receivers lying about whether the request was
approved or about the approved rate, and of routers in collusion to
misuse Quick-Start. Section 9.5 discusses potential problems with
...
... sender using a Rate Request that
was inappropriately large, or thinking that a request was approved
when it was in fact denied by at least one router along the path.
This inappropriate use of Quick-Start ...
...
Section 9.6 discusses a potential attack on the routers' processing
and state load from an attack ...
... Quick-Start Request
is erroneously considered approved by the sender without the routers
in the tunnel having individually approved the request, causing a
...
... throughput with low delay and low packet-loss rates.
Quick-Start would not give routers more control over the decrease
rates of active connections ...
... discussion
of the relative benefits of approaches that use no explicit
information from routers, and of approaches that use more fine-
grained feedback from routers as part of a larger congestion control ...
... information from routers, and of approaches that use more fine-
grained feedback from routers as part of a larger congestion control
mechanism. We discuss several classes ...
... packet streams to learn about the available bandwidth, without
explicit information from routers. These techniques would not allow
a start-up as fast as that available from Quick-Start ...
... than the current Slow-Start. While it seems clear that approaches
*without* explicit feedback from the routers will be strictly less
powerful than is possible *with* explicit feedback, it is also
possible that approaches that are more aggressive than Slow-Start ...
... Slow-Start are
possible without the complexity involved in obtaining explicit
feedback from routers.
Periodic packet streams ...
... transport protocols to learn of available bandwidth without
explicit feedback from the router seems useful, we note that there
are several fundamental advantages of explicit feedback from routers.
...
... explicit feedback from the router seems useful, we note that there
are several fundamental advantages of explicit feedback from routers.
(1) Explicit feedback is faster than implicit feedback:
...
...
(1) Explicit feedback is faster than implicit feedback:
One advantage of explicit feedback from the routers is that it
allows the transport sender ...
... A.2. Optimistic Sending without Explicit Information from Routers ...
... to start with a large initial window without explicit permission from
the routers and without bandwidth estimation techniques and for the
first packet of the initial window to contain information, such as
...
... the size or sending rate of the initial window. The proposal would
be that congested routers would use this information in the first
data packet to drop or delay many or all of the packets from that
...
... initial window. In this way, a flow's optimistically large initial
window would not force the router to drop packets from competing
flows in the network ...
... network. Such an approach would seem to require some
mechanism for the sender to ensure that the routers along the path
understood the mechanism for marking the first packet of a large
initial window.
...
... One question would be the potential complications of incremental
deployment, where some of the routers along the path might not
understand the packet information describing the initial window.
...
... where the transport protocol collects explicit information from the
routers along the path.
An IP Option ...
... IP option would query the
routers along the path about the smallest available free buffer size.
Also, the IP option ...
... PTP) includes a proposal for a
single PTP packet that would collect information from routers along
the path from the sender to the receiver ...
... Additional proposals for end nodes to collect explicit information
from routers include one variant of Explicit Transport Error