Dear All,
I've been through LINK again. When PILC was formed,
the expectation was that
this document would be our primary output, with the
(aready-approved) BCPs
helping to bandaid TCP over already-deployed
subnetwork technologies. I
believe that Phil and Mark have met this expectation,
with help from a number
of others.
I do have a few comments on version 11...
Spencer
------------
1 Introduction and Overview
I think the following is too polite!
Because IP is so simple, consideration 2 is more of
an issue than
consideration 1. I.e., subnetwork designers make
many more errors of
commission than errors of omission. But certain
enhanced Internet
features, such as multicasting and
quality-of-service, benefit
significantly from support from the underlying
subnetworks beyond
that necessary to carry "traditional" unicast,
best-effort IP.
I propose
IP transport requirements are so minimal that
consideration 2 is more
of an issue than consideration 1. Subnetwork
designers make many more
errors of commission than errors of omission.
o A frequent error of commission is designing a
subnetwork that provides
a high level of subnetwork-level reliability for
IP datagrams, at a
corresponding high cost in latency and jitter -
even though higher-level
protocols can't assume this level of reliability
for all IP paths and
must duplicate this reliability if it's needed.
o When subnetwork designers do make errors of
omission, it's usually
by not providing subnetwork-level support for
multicast transport
and quality-of-service mechanisms - or anything
else beyond
"traditional" unicast, best-effort IP transport.
Would it make sense to point to RFC 3135 at the end of
the following paragraph?
However, partial duplication of functionality in a
lower layer can
*sometimes* be justified by performance, security
or availability
considerations. Examples include link-layer
retransmission to improve
the performance of an unusually lossy channel,
e.g., mobile radio;
link level encryption intended to thwart traffic
analysis; and
redundant transmission links to improve
availability, increase
throughput, or to guarantee performance for certain
classes of
traffic. Duplication of protocol function should
be done only with
an understanding of system level implications,
including possible
interactions with higher-layer mechanisms.
2 Maximum Transmission Units (MTUs) and IP
Fragmentation
I had too may "it is" in this paragraph to parse
quickly:
If optional header compression [RFC1144] [RFC2507]
[RFC2508]
[RFC3095] is used, however, it is required that the
link framing
indicate frame length as it is needed for the
reconstruction of the
original header.
I propose that we use more nouns, as follows:
If optional header compression [RFC1144] [RFC2507]
[RFC2508]
[RFC3095] is used, however, link framing mechanisms
are required to
indicate frame length as this information is needed
to reconstruct
the original header.
Do we still think P-MTU black holes are a sufficent
problem that we
will still include this problem on the following list
of justifications
for support of large MTU sizes? (If so, should P-MTU
discovery still be
on the 2.5G3G list of recommendations? But that's not
a LINK question...)
The Path MTU Discovery procedure, the persistence
of path MTU black
holes, and the deletion of router fragmentation in
IPv6 reflects a
consensus of the Internet technical community that
router
fragmentation is best avoided. This requires that
subnetworks support
MTUs that are "reasonably" large. The smallest MTU
permitted in IPv4
by [RFC791] is 68 bytes, but such a small value
would clearly be
inefficient. Because IPv6 omits fragmentation by
routers, [RFC 2460]
specifies a larger minimum MTU of 1280 bytes. Any
subnetwork with an
internal packet payload smaller than 1280 bytes
must implement a
mechanism that performs fragmentation/reassembly of
IP packets
to/from subnetwork frames if it is to support IPv6.
Is there an interaction here between internal
fragmentation and
insertion of a smaller/higher priority packet during
transmission
of a larger/lower priority packet, for reasons
described in 2.1, and using
the multiplexing mechanism described in 2.1?
If a subnetwork cannot directly support a
"reasonable" MTU with
native framing mechanisms, it should internally
fragment. That is, it
should transparently break IP packets into internal
data elements and
reassemble them at the other end of the subnetwork.
This leaves the question of what is a "reasonable"
MTU. Ethernet (10
and 100 Mb/s) has a MTU of 1500 bytes, and because
of its ubiquity
Isn't 1500 bytes the limit for all 802.3s (including 1
and 10 Gb/s)?
few Internet paths have MTUs larger than this
value. This severely
limits the utility of larger MTUs provided by other
subnetworks.
Meanwhile larger MTUs are increasingly desirable on
high speed
subnetworks to reduce the per-packet processing
overhead in host
computers, and implementers are encouraged to
provide them even
though they may not be usable when Ethernet is also
in the path.
Various "tunneling" schemes, such as IP Security
[RFC2406] treat IP
as a subnetwork for IP. Since tunneling adds
header overhead, it can
Doesn't insertion of MPLS headers have the same
effect?
trigger fragmentation even when the same physical
subnetworks (e.g.,
Ethernet) are used on both sides of the IP router.
Tunneling has made
it more difficult to avoid router fragmentation and
has increased the
incidence of path MTU black holes. Larger
subnetwork MTUs may help to
alleviate this problem.
I think it's also reasonable to point out that P-MTU
discovery uses a
table of "likely" MTU sizes that doesn't map very well
to what used to
be full-sized MSSes that are being tunneled - the
fallback to the first
working MTU in the table may be quite a bit smaller
than the un-tunneled
P-MTU... I wonder if this table will ever be
updated...
2.1 Choosing the MTU in Slow Networks
In slow networks, the largest possible packet may
take a considerable
time to send. Interactive response time should not
exceed the well-
Can (should) we say "Round-trip times for interactive
responses should
not exceed"?
Also, can we point to RFC 1144 as a source for the
100-200 ms requirement
for interactive response?
known human factors limit of 100 to 200 ms. This
includes all sources
of delay: electromagnetic propagation delay,
queuing delay, and the
store-and-forward time, i.e,. the time to transmit
a packet at link
speed.
3 Framing on Connection-Oriented Subnetworks
(no comments in this section)
4 Connection-Oriented Subnetworks
Because Internet traffic is typically bursty and
transaction-
oriented, it is often difficult to pick an optimal
idle timeout. If
the timeout is too short, subnetwork connections
are opened and
closed rapidly, possibly over-stressing its call
management system
(especially if was designed for voice traffic
holding times). If the
timeout is too long, subnetwork connections are
idle much of the
time, wasting any resources dedicated to them by
the subnetwork.
Can we also add the following:
Subscribers may also be charged differently
depending on whether
a subnetwork leaves idle connections in place using
a
relatively-long idle timer or tears down idle
connections with
little delay and reestablishes these connections
after a short
period of time. If it makes sense to do so,
subscribers should be
given control over this behavior (for example, PPP
implementations
might allow subscribers to control an idle timer
for locally-
initiated dialup connections.
Should be "is used TO support IP" in the following
sentence.
In any event, if an SNDCF that opens and closes
subnet connections is
used support IP, care should be taken to make sure
that call
processing in the subnet can keep up with
relatively short holding
times.
5 Broadcasting and Discovery
Subnetworks fall into two categories:
point-to-point and shared. A
point-to-point subnet has exactly two endpoint
components (hosts or
routers); a shared link has more than two, using
either an inherent
broadcast media (e.g., Ethernet, radio) or on a
switching layer
hidden from the network layer (switched Ethernet,
Myrinet [MYR],
ATM). Switched subnetworks handle broadcast by
copying broadcast
Could this sentence say "by forwarding broadcast
packets on all other
interfaces to ensure..."?
packets to ensure each end system receives a copy
of each packet.
Could we insert "Centralized databases also insert new
failure points and
scaling hot-spots into the network." before the last
sentence in the
following paragraph?
The lack of broadcast can impede the performance of
these protocols,
or render them inoperable (e.g. DHCP). ARP-like
link address lookup
can be provided by a centralized database, but at
the expense of
potentially higher response latency and the need
for nodes to have
explicit knowledge of the ARP server address.
Shared links should
support native, link-layer subnet broadcast.
6 Multicasting
Receivers also need to be designed to accept
packets addressed to
some number of multicast addresses in addition to
the unicast packets
specifically addressed to them. How many multicast
addresses need to
be supported by a host depends on the requirements
of the associated
host; at least several dozen will meet most current
needs.
The last phrase doesn't parse well for me. Is it
saying "few hosts
must accept multicast packets from more than a few
dozen multicast
addresses"?
On low-speed networks the multicast address
recognition function may
be readily implemented in host software, but on
high speed networks
it should be implemented in subnetwork hardware.
This hardware need
not be complete; for example, many Ethernet
interfaces implement a
"hashing" function that passes all of the multicast
(and unicast)
traffic to which the associated host subscribes,
plus some small
fraction of multicast traffic to which the host
does not subscribe.
Host/router software then has to discard the
unwanted packets that
pass the hardware filter.
There does not need to be a one-to-one mapping
between subnetwork
multicast address and IP multicast address. An
address overlap may
significantly degrade the filtering capability of a
receiver's
hardware multicast address filter. A subnetwork
supporting only
Is this sentence saying "If more than one IP multicast
address makes into
a subnetwork multicast address, this many-to-one
mapping may significantly
degrade the filtering capacity of a receiver's
hardware multicast address
filter", or something else? "Address overlap" is too
ambiguous for me...
broadcast should use this service for multicast and
must rely on
software filtering.
7 Bandwidth on Demand (BoD) Subnets
Long delay BoD subnets pose problems similar to
connection oriented
networks in anticipating traffic. While connection
oriented subnets
hold idle channels open expecting new data to
arrive, BoD subnets
request channel access based on buffer occupancy
(or expected buffer
occupancy) on the sending port. Poor performance
will likely result
if the sender does not anticipate additional
traffic arriving at that
I'm confused here. Is this sentence saying "Poor
performance will likely
resuly if the sending host does not queue additional
outgoing traffic
while the sender is waiting for its transmission
request to be granted"?
If so, I agree. If not, can we talk? I may not
disagree, I just don't
understand the point being made.
port during the time it takes to grant a
transmission request. It is
recommended that the algorithm have the capability
to extend a hold
on the channel for data that has arrived after the
original request
was generated (this may done by piggybacking new
requests on user
data).
There are a wide variety of BoD protocols
available. However, there
has been relatively little comprehensive research
on the interactions
between the BoD mechanisms and Internet protocol
performance.
Research on some specific mechanisms is available
(e.g., [AR02]).
One item that has been studied is TCP's
retransmission timer [KY02].
BoD systems can cause spurious timeouts when
adjusting from a
relatively high data rate to a relatively low data
rate. In this
case, TCP's transmitted data takes longer to get
through the network
than predicted by the retransmission timeout (RTO)
and therefore the
TCP sender is prone to resending a segment
prematurely.
Could we also include the observation that delays to
acquire a shared
control channel may also be reflected as sudden and
unpredictable "spikes"
in apparent round-trip times, making RTO values
"spike" unpredictably
as well? I'm trying to say that it's not just the
change in available
bandwidth, but delays encountered while changing
available bandwidth
as well...
8 Reliability and Error Control
In the Internet architecture, the ultimate
responsibility for error
recovery is at the end points. The Internet may
occasionally drop,
corrupt, duplicate or reorder packets, and the
transport protocol
(e.g., TCP) or application (e.g., if UDP is used as
the transport
protocol) must recover from these errors on an
end-to-end basis.
I'm not sure this is strictly true - I'm thinking of
RTP over UDP,
where the RTP sender may use RTCP indications of loss
to lower its sending
rates. Is this "recovering" in the "reliability and
error control"
sense? I think it's not "must recover", but "recovers
if necessary".
Error recovery in the subnetwork is therefore
justified only to the
extent that it can enhance overall performance. It
is important to
recognize that a subnetwork can go too far in
attempting to provide
error recovery services in the Internet
environment. Subnet
reliability should be "lightweight", i.e., it only
has to be "good
enough", *not* perfect.
Can we add something like:
Applications have no way of accepting a lower level of
reliability
(perhaps as a tradeoff for lower latency) than the
subnetwork provides.
"Reliability" is a good thing until it prevents users
from using an
application over a too-reliable subnetwork.
In this section we discuss how to analyze
characteristics of a
subnetwork to determine what is "good enough". The
discussion below
focuses on TCP, which is the most widely used
transport protocol in
the Internet. It is widely believed (and is a
stated goal within the
IETF) that non-TCP transport protocols should
attempt to be "TCP-
friendly" and have many of the same performance
characteristics.
Is this true? I thought the point of SCTP and DCP was
have "safe"
behavior when facing congestion, but to vary other
dimensions of
performance.
Thus, the discussion below should be applicable
even to portions of
the Internet where TCP may not be the predominant
protocol.
I think the discussion is applicable, but not just
because all transport
protocols have the same performance characteristics as
TCP.
8.1 TCP vs Link-Layer Retransmission
The use of ECC to detect transmission errors so
that retransmissions
(hopefully without errors) can be requested is
widely known as "ARQ"
(Automatic Repeat Request).
Can we make it "Automatic Repeat reQuest", to match
the acronym?
This inter-layer "competition" might lead to the
following wasteful
situation. When the link layer retransmits (parts
of) a packet, the
link latency momentarily increases. Since TCP bases
its
retransmission timeout on prior measurements of
end-to-end latency,
including that of the link in question, this sudden
increase in
latency may trigger an unnecessary retransmission
by TCP of a packet
that the link layer is still retransmitting. Such
spurious end-to-
end retransmissions generate unnecessary load and
reduce end-to-end
throughput. One may even have multiple copies of
the same packet in
the same link queue at the same time. In general,
one could say the
competing error recovery is caused by an inner
control loop (link-
layer error recovery) reacting to the same signal
as an outer control
loop (end- to-end error recovery) without any
coordination between
the loops. Note that this is solely an efficiency
issue; TCP
continues to provide reliable end-to-end delivery
over such links.
Can we append ", although this delivery is being
slowed by unnecessary
link-layer transmissions"?
8.2 Recovery from Subnetwork Outages
Under these circumstances TCP will, after each
unsuccessful
retransmission, wait even longer before trying
again; this is its
"exponential back-off" algorithm. Furthermore, TCP
will not discover
that the subnetwork outage has ended until its next
retransmission
attempt. If TCP has backed off, this may take some
time. This can
Can we say "this may take a number of minutes."? I'm
still talking to
people who find these long timer backoffs surprising.
lead to extremely poor TCP performance over such
subnetworks.
It is therefore highly desirable that a subnetwork
subject to outages
not silently discard packets during an outage.
Ideally, it should
define an interface to the next higher layer (i.e.,
IP) that allows
it to refuse packets during an outage, and to
automatically ask IP
for new packets when it is again able to deliver
them. If it cannot
do this, then the subnetwork should hold onto at
least some of the
We're saying "at least some" in this paragraph and
"only a single packet
per TCP connection, including ACKs" in the next
paragraph. Can we make
one recommendation?
packets it accepts during an outage and attempt to
deliver them when
the subnetwork comes back up. When packets are
discarded, IP should
This is "When outbound packets are discarded,", right?
be notified so that the appropriate ICMP messages
can be sent.
Only a single packet per TCP connection, including
ACKs, need be held
in this way to cause the TCP sender to recover from
the additional
losses once the flow resumes [ARQ-DRAFT].
(See previous note about the right number of packets
to hang onto during
outages.)
Is there a maximum period of time that a subnetwork
should hang onto a
packet? I don't feel good about "longer than 2 * MSL"
- would sending
packets that are older than this cause problems?
8.3 CRCs, Checksums and Error Detection
The TCP [RFC793], UDP [RFC768], ICMP, and IPv4
[RFC791] protocols all
use the same simple 16-bit 1's complement checksum
algorithm to
detect corrupted packets. The IPv4 checksum
protects only the IPv4
header, while the TCP, ICMP, and UDP checksums
provide end-to-end
error detection for both the transport pseudo
header (including
network and transport layer information) and the
transport payload
data. Protection of the data is optional for
applications using UDP
[RFC768].
Do we think UDP checksums are "optional but
recommended", based on the
NFS war stories, or is this going too far? My
understanding is that
UDP checksums are enabled host-wide on most
implementations - would
this make turning UDP checksums off less desirable,
because errored
packets might be delivered to any running application
on the host?
One way to provide additional protection for an
IPv4 or IPv6 header
is by the authentication and packet integrity
services of the IP
Security (IPSEC) protocol [RFC2401]. However, this
may not be a
choice available to the subnetwork designer.
Is this just saying IPSEC AH is an IP mechanism, or is
it saying more?
8.4 How TCP Works
TCP uses sequence numbering and acknowledgments
(ACKs) on an end-to-
end basis to provide reliable, sequenced, once-only
delivery. TCP
ACKs are cumulative, i.e., each implicitly ACKs
every segment
received so far. If an ACK is not received, the
acknowledgment value
Isn't this "implicitly ACKs all previously
unacknowledged data in the
sender's outgoing window"?
carried in the cumulative packet will cease to
advance.
Since the most common cause of packet loss is
congestion, TCP treats
packet loss as an Internet congestion indicator.
This happens
automatically, and the subnetwork need not know
anything about IP or
TCP. It simply drops packets whenever it must,
though some packet-
dropping strategies (e.g., RED) are more fair to
competing flows than
others.
Is this a fairness issue? I might have said "reduce
the effect of
congestion on competing flows, compared to others
(tail drop)."
The following seems to ignore slow start:
TCP recovers from packet losses in two different
ways. The most
important is the retransmission timeout. If an ACK
fails to arrive
after a certain period of time, TCP retransmits the
oldest unacked
packet. Taking this as a hint that the network is
congested, TCP
waits for the retransmission to be ACKed before it
continues, and it
gradually increases the number of packets in flight
as long as a
timeout does not occur again.
Restart behavior is more correctly described in the
next paragraph -
can we drop the last clause of the previous paragraph
("... and it
gradually ...")? Then we go straight into:
A retransmission timeout can impose a significant
performance
penalty, as the sender is idle during the timeout
interval and
restarts with a congestion window of 1 following
the timeout. To
allow faster recovery from the occasional lost
packet in a bulk
transfer, an alternate scheme known as "fast
recovery" was introduced
[RFC2581] [RFC2582] [RFC2914] [TCPF98].
This discussion of fast recovery seems so loose that
it's actually about
fast retransmit:
Fast recovery relies on the fact that when a single
packet is lost in
"Fast retransmit relies on the fact that even when one
or more oackets
are lost in a bulk transfer, the receiver may continue
to return ACKs
to ..."
a bulk transfer, the receiver continues to return
ACKs to subsequent
data packets that do not actually acknowledge any
newly-received
data. These are known as "duplicate
acknowledgments" or "dupacks".
The sending TCP can use dupacks as a hint that a
packet has been lost
and retransmit it without waiting for a timeout.
Dupacks effectively
constitute a negative acknowledgment (NAK) for the
packet sequence
number in the acknowledgment field. TCP waits
until a certain number
of dupacks (currently 3) are seen prior to assuming
a loss has
occurred; this helps avoid an unnecessary
retransmission during out-
of-sequence delivery.
A new technique called "Explicit Congestion
Notification" (ECN)
[RFC3168] allows routers to directly signal
congestion to hosts
without dropping packets. This is done by setting
a bit in the IP
header. Since this is currently an optional
behavior (and, longer
term, there will always be the possibility of
congestion in portions
of the network which don't support ECN), the lack
of an ECN bit must
NEVER be interpreted as a lack of congestion.
Thus, for the
"lack of congestion - especially since ECN-capable
routers still drop
packets at high levels of congestion, instead of
continuing to send
traffic on congested links. Thus, fot the foreseeable
future ..."
foreseeable future, TCP must interpret a lost
packet as a signal of
congestion.
The TCP "congestion avoidance" [RFC2581] algorithm
maintains a
congestion window (cwnd) controlling the amount of
data TCP may have
in flight at any moment. Reducing cwnd reduces the
overall bandwidth
obtained by the connection; similarly, raising cwnd
increases the
performance, up to the limit of the available
bandwidth.
"reduces the overall bandwidth that the sender will
attempt to use for
the connection; similarly ..."
TCP probes for available network bandwidth by
setting cwnd to one
packet and then increasing it by one packet for
each ACK returned
from the receiver. This is TCP's "slow start"
mechanism. When a
packet loss is detected (or congestion is signaled
by other
mechanisms), cwnd is reset to one and the slow
start process is
repeated until cwnd reaches one half of its
previous setting before
the reset.
"This is the "slowstart threshold", or ssthresh."
Cwnd continues to increase past this point, but at
a much
slower rate than before. If no further losses
occur, cwnd will
ultimately reach the window size advertised by the
receiver.
8.5 TCP Performance Characteristics
No comments.
8.5.1 The Formulae
No comments.
8.5.2 Assumptions
Both of these formulae allow BW to become infinite
if there is no
loss. This is because an Internet path will drop
packets at
bottleneck queues if the load is too high. Thus, a
completely
lossless TCP/IP network can never occur (unless the
network is being
underutilized).
I don't understand the last sentence in the previous
paragraph. Is it
saying "A completely lossless TCP/IP connection can
never occur, unless
the receiver is using a receive window smaller than
the bandwidth-delay
product"?
8.5.3 Analysis of Link-Layer Effects on TCP
Performance
No comments.
9 Quality-of-Service (QoS) considerations
No comments.
10 Fairness vs Performance
No comments.
11 Delay Characteristics
No comments.
12 Bandwidth Asymmetries
Some subnetworks may provide asymmetric bandwidth
(or may cause TCP
packet flows to experience asymmetry in the
capacity) and the
Internet protocol suite will generally still work
fine. However,
there is a case when such a scenario reduces TCP
performance. Since
TCP data segments are 'clocked' out by returning
acknowledgments TCP
senders are limited by the rate at which ACKs can
be returned
[BPK98]. Therefore, when the ratio of the
bandwidth of the
subnetwork carrying the data to the bandwidth of
the subnetwork
carrying the acknowledgments is too large, the slow
return of of the
ACKs directly impacts performance. Since ACKs are
generally smaller
than data segments, TCP can tolerate some
asymmetry, but as a general
Should we say "TCPs can tolerate substantial
assymetry, ..."?
rule designers of subnetworks should be aware that
subnetworks with
significant asymmetry can result in reduced
performance, unless
issues are taken to mitigate this [asym-id].
Several strategies have been identified for
reducing the impact of
asymmetry of the network path between two TCP end
hosts, e.g. [asym-
id]. These techniques attempt to reduce the number
of ACKs
transmitted over the return path (low bandwidth
channel) by changes
at the end host(s), and/or by modification of
subnetwork packet
forwarding. While these solutions may mitigate the
performance issues
caused by asymmetric subnetworks, they do have
associated cost and
may have other implications. A fuller discussion of
strategies and
their implications is provided in [asym-id].
The IESG documents under review is showing Allison
holding this token.
13 Buffering, flow & congestion control
No comments.
14 Compression
We make a stronger recommendation that subnetworks
operating at low
speed or with small MTUs compress IP and
transport-level headers (TCP
and UDP) using several header compression schemes
developed within
the IETF. An uncompressed 40-byte TCP/IP header
takes about 33
milliseconds to send at 9600 bps. "VJ" TCP/IP
header compression
Can we introduce this as "Van Jacobson TCP/IP header
compression", to be
consistent with what we settled on in 2.5G/3G?
[RFC1144] compresses most headers to 3-5 bytes,
reducing transmission
time to several milliseconds. This is especially
beneficial for
small, latency-sensitive packets in interactive
sessions.
15 Packet Reordering
No comments.
16 Mobility
No comments.
17 Routing
No comments.
18 Security Considerations
Too many transitions in this paragraph?
Nonetheless, end-to-end security mechanisms are not
used as widely as
might be desired. However, the group could not
reach consensus on
whether subnetwork designers should be actively
encouraged to
implement mechanisms to protect user data.
I propose:
Although end-to-end security mechanisms are not
used as widely as
might be desired, the PILC working group could not
reach consensus on
whether subnetwork designers should be actively
encouraged to
implement mechanisms to protect user data.
And can we drop the "however, " in this paragraph? It
doesn't seem to be
in contrast to anything...
However, traffic analysis is a notoriously subtle
and difficult
threat to understand and defeat, far more so than
threats to
confidentiality and integrity. We therefore urge
extreme care in the
design of subnetwork security mechanisms
specifically intended to
thwart traffic analysis.
Not to be pedantic, but [WFBA2000] isn't about buffer
overruns in I/O
system calls - it's about buffer overruns in the
standard C library:
In addition, well-designed security protocols can
be compromised by
implementation defects. Examples of such defects
include use of
predictable pseudo-random numbers [RFC1750],
vulnerability to buffer
overflow attacks due to unsafe use of certain I/O
system calls
[WFBA2000], and inadvertent exposure of secret
data.
References
[AP99] M. Allman, V. Paxson, On Estimating
End-to-End Network Path
Properties, In Proceedings of ACM SIGCOMM 99.
A URL for this paper is:
http://www.acm.org/sigcomm/sigcomm99/papers/session7-3.html
[AR02] G. A,car and C. Rosenberg, Weighted Fair
Bandwidth-on-Demand
(WFBoD) for Geo-Stationary Satellite Networks with
On-Board
Processing, Special Issue on Broadband Satellite
Systems: A Network
Perspective, Computer Networks, accepted on July
13, 2001. To appear
in 2002.
The best URL I could find for this paper was
http://www.iis.ee.ic.ac.uk/~g.acar/Research.html#WFBoD
[asym-id] H. Balakrishnan, V. N. Padmanabhan, G.
Fairhurst, M,
Sooriyabandara. "TCP Performance Implications of
Network Path
Asymmetry", work in progress as internet-draft,
draft-ietf-pilc-
asym-07.txt, November 2001.
This draft should have already expired. Aaron - are we
going to progress
it?
[ARQ-DRAFT] Fairhurst, G., and L. Wood, Advice to
link designers on
link Automatic Repeat reQuest (ARQ), work in
progress as internet-
draft, draft-ietf-pilc-link-arq-issues-03.txt,
August 2001.
This is now version 04, from March 2002.
[ATMFTM] The ATM Forum, "Traffic Management
Specification, Version
4.0", April 1996, document af-tm-0056.000
(www.atmforum.com).
A more complete URL is
ftp://ftp.atmforum.com/pub/approved-specs/af-tm-0056.000.pdf
[BA02] Ethan Blanton, Mark Allman. On Making TCP
More Robust to
Packet Reordering. ACM Computer Communication
Review, 32(1), January
2002.
A complete URL is
http://www.acm.org/sigcomm/ccr/archive/2002/jan02/ccr-200201-allman.pdf
[BPK98] Hari Balakrishnan, Venkata Padmanabhan,
Randy H. Katz. 'The
Effects of Asymmetry on TCP Performance." ACM
Mobile Networks and
Applications (MONET), 1998.
A complete URL is
http://daedalus.cs.berkeley.edu/publications/tcpasym-mobicom97.ps.gz
[Crypto9912] Schneier, Bruce "European Cellular
Encryption
Algorithms" Crypto-Gram (December 15, 1999)
www.counterpane.com
A complete URL is
http://www.counterpane.com/crypto-gram-9912.html
[DOCSIS3] W.S. Lai, "DOCSIS-Based Cable Networks:
Impact of Large
Data Packets on Upstream Capacity", 14th ITC
Specialists Seminar on
Access Networks and Systems, Barcelona, Spain,
April 25-27, 2001.
A complete URL is
http://www.att.com/networkandperformance/docs/ndrp_itc0401b.doc
[ES00] David A. Eckhardt and Peter Steenkiste,
"Effort-limited Fair
(ELF) Scheduling for Wireless Networks, Proceedings
of IEE Infocom
2000.
The closing quote mark is missing (after "Networks").
A complete URL is
http://www.ieee-infocom.org/2000/papers/266.ps
[FB00] Firoiu V., and Borden M., "A Study of Active
Queue Management
for Congestion Control" to appear in Infocom 2000
The paper has already appeared. The URL is
http://www.ieee-infocom.org/2000/papers/405.pdf
[IEEE80211] IEEE 802.11 Wireless LAN standard.
Available from
http://standards.ieee.org/catalog/IEEE802.11.html.
This is now freely downloadable from
http://standards.ieee.org/getieee802/download/802.11-1999.pdf
[LKJK02] R. Ludwig, A. Konrad, A. D. Joseph, R. H.
Katz, "Optimizing
the End-to-End Performance of Reliable Flows over
Wireless Links",
Kluwer/ACM Wireless Networks Journal, Vol. 8, Nos.
2/3, pp. 289-299,
March-May 2002.
A Complete URL is
http://iceberg.cs.berkeley.edu/papers/Ludwig-Mobicom99/
[LRKOJ99] R. Ludwig, B. Rathonyi, A. Konrad, K.
Oden, A. Joseph,
Multi-Layer Tracing of TCP over a Reliable Wireless
Link, pp.
144-154, In Proceedings of ACM SIGMETRICS 99.
Need quotes around title. A complete URL is
http://iceberg.cs.berkeley.edu/papers/Ludwig-Sigmetrics99/
[LS00] R. Ludwig, K. Sklower, The Eifel
Retransmission Timer, ACM
Computer Communication Review, Vol. 30, No. 3, July
2000.
Need quotes around title. A complete URL is
http://www.acm.org/sigcomm/ccr/archive/2000/july00/ccr_200007-ludwig.html
[MBB00] May, M., Bonald, T., and Bolot, J-C.,
"Analytic Evaluation of
RED Performance" to appear INFOCOM 2000
The paper has appeared. A complete URL is
http://www.ieee-infocom.org/2000/papers/369.ps
[MBDL99] May, M., Bolot, J., Diot, C., and Lyles,
B., "Reasons not to
deploy RED", technical report, June 1999.
A complete URL is
http://www-sop.inria.fr/rodeo/personnel/mmay/may_red.html
[GM02] Luigi Alfredo Grieco1, Saverio Mascolo, "TCP
Westwood and Easy
RED to Improve Fairness in High-Speed Networks",
Proceedings of the
7th International Workshop on Protocols for
High-Speed Networks,
April 2002.
A complete URL is
http://www.cs.ucla.edu/NRL/hpi/papers/2002-pfhsn-0.pdf.gz
[MSMO97] M. Mathis, J. Semke, J. Mahdavi, T. Ott,
"The Macroscopic
Behavior of the TCP Congestion Avoidance
Algorithm", Computer
Communication Review, volume 27, number 3, July
1997.
A complete URL is
http://www.psc.edu/networking/papers/model_abstract.html
[PFTK98] Padhye, J., Firoiu, V., Towsley, D., and
Kurose, J.,
"Modeling TCP Throughput: a Simple Model and its
Empirical
Validation", UMASS CMPSCI Tech Report TR98-008,
Feb. 1998.
A complete URL is
ftp://gaia.cs.umass.edu/pub/Padhye-Firoiu98-TCP-throughput-TR.ps
[RF95] Romanow, A., and Floyd, S., "Dynamics of TCP
Traffic over ATM
Networks". IEEE JSAC, V. 13 N. 4, May 1995, p.
633-641.
A complete URL is
http://www-nrg.ee.lbl.gov/papers/tcp_atm.pdf
[RFC1812]
Needs details!
[Schneier3] Schneier, Bruce "Why Cryptography is
Harder Than it
Looks", www.counterpane.com
A complete URL is
http://www.counterpane.com/whycrypto.html
[TCPF98] Dong Lin and H.T. Kung, "TCP Fast Recovery
Strategies:
Analysis and Improvements", IEEE Infocom, March
1998. Available
from:
"http://www.eecs.harvard.edu/networking/papers/infocom-tcp-
final-198.pdf"
This URL is broken:
[WFBA2000] David Wagner, Jeffrey S. Foster, Eric
Brewer and Alexander
Aiken, "A First Step Toward Automated Detection of
Buffer Overrun
Vulnerabilities", Proceedings of NDSS2000, or
www.berkeley.edu:80/~daw/papers/
A correct URL is http://www.cs.berkeley.edu/~daw/papers/overruns-ndss00.ps
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
_______________________________________________
pilc mailing list
pilc@ietf.org
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/
This archive was generated by hypermail 2b29 : Tue Jun 11 2002 - 13:43:30 EDT