Mark,
Thanks.
Here are some comments:
The architecture of the Internet was heavily influenced by the end-
to-end principle, and in our view it was crucial to the Internet's
success.
I've always considered this to be a bit of an overstatement, especially
in light of draft-iab-arch-changes-00. Suggest toning this down a bit.
A third example of link-layer multiplexing is the Data Over Cable
Service Interface Specifications. [DOCSIS1] [DOCSIS2] [DOCSIS3]
DOCSIS version 1.1 introduces an internal fragmentation and
Only one of the references applies here. Suggest: "A third example of
data link layer fragmentation is contained in the Data Over Cable
Service Interface Specification (DOCSIS) version 1.1 [DOCSIS2]." By the
way, text in this section is a bit inaccurate in its use of the term
multiplexing to cover the specific case of multiplexing that reduces
head-of-line blocking for real time traffic. You might want to try to
clean this up.
There are several approaches to the problem. The first is to encode
each IP packet into one or more SNDUs, with no SNDU containing pieces
of more than one IP packet, and padding out the last SNDU of the
AAL2 allows packets to be multiplexed into cell streams in ways that the
start of a packet does not correspond to the start of a cell. See
draft-ietf-pppext-ppp-over-aal2-02.txt
as the first in a new IP packet. The AAL5 (ATM Adaption Layer 5)
scheme used with ATM is an example of this approach, though it adds
other features, including a payload length field and a payload CRC.
The payload length field and CRC are an integral part of delineation
(needed to detect loss of the last cell in an SDU), as well as being
needed to protect against bit errors and erasures. Suggest removing the
last clause of the last sentence.
In AAL5, the 1-bit per segment flag, carried in the ATM header,
The ATM User-User Indication (its proper name) is not a one-bit per cell
(again, the proper name) flag, since the field in which it is encoded in
fact encodes 8 values in 3 bits. The sentence should read: "In AAL5,
the ATM User-User Indication, which is encoded in the Payload Type field
of an ATM cell,..."
indicates the end of a packet. (This bit is not protected by the ATM
checksum, indicating the need for an end-to-end checksum.) The
Not true. The HEC covers the entire cell header. Delete the
parenthetical statement.
packet control information (trailer) is located at the end of the
segment. Placing the trailer in a fixed position may simplify
hardware reassembly.
Last sentence is gratuitous, and facilitating hardware reassembly was at
or near the bottom of a list of rationales for placing it where it was
placed. Suggest removing this.
The ideal subnetwork for IP is connectionless. Connection-oriented
networks that dedicate minimal resources to each connection (e.g.,
ATM) are a distant second, and connection-oriented networks that
dedicate a fixed amount of capacity to each connection (e.g., the
PSTN, including ISDN) are the least efficient. If such subnetworks
must be used to carry IP, their call-processing systems should be
capable of rapid call set-up and tear-down.
This paragraph has always kinda bothered me as being conclusory.
Suggest the following:
"Purely connectionless subnets (such as Ethernet), which have no state
and dynamically share resources, are optimal to supporting best effort
IP, which is stateless and dynamically shares resources.
Connection-oriented packet networks (such as ATM and Frame Relay), which
have state and dynamically share resources, are less optimal, since best
effort IP does not benefit from the overhead of creating and maintaining
state. Connection-oriented circuit switched networks (including the
PSTN and ISDN) both have state and statically allocate resources for a
call, and thus not only require state creation and maintenance overhead,
but also do not benefit from the efficiencies of statistical sharing of
capacity inherent in IP.
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."
Or words to that effect. You might even want to move that last bit up a
paragraph or two.
Bandwidth on Demand (BoD) Subnets
Wireless networks, including both satellite and terrestrial, may use
Bandwidth on Demand (BoD). Bandwidth on demand, which is implemented
systems, is currently one proposed mechanism to efficiently share
I know we went throught this once, but the definition of BoD, and what's
encompassed and conflicts with other use of this term are really not
clear. Are DOCSIS upstream and other contention-reservation systems
BoD, for example? How about ATM/Frame Relay SVCs? ISDN? Is there some
better way of scoping this thing?
Might want to change that to "... is one mechanism that is used to..."
(it's no longer a proposal, it's being used for better or worse).
Unlike ARQ, FEC was seldom used for telecommunications outside of
deep space links until the 1990s. It is now nearly universal in
Seems to me that trellis coding came into voiceband modems in the
mid-1980s, and that GEOs and military stuff were using it even earlier.
Some systems use hybrid combinations of ARQ layered atop FEC; V.90
dialup modems with V.42bis error control are one example. Most errors
are corrected by the trellis (FEC) code within the V.90 modem, and
most that remain are detected and corrected by the ARQ mechanisms in
V.42bis.
Two corrections: V.90 has trellis coding only in the upstream (the
reasons are too complex for my simple mind to capture). Text can either
read: "V.90 modems (in the upstream direction)..." or "V.34
modems..." Also, MNP4 and LAPM are defined in in V.42, not V.42
bis.
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
packets it accepts during an outage and attempt to deliver them when
the subnetwork comes back up. When packets are discarded, IP should
be notified so that the appropriate ICMP messages can be sent.
Shouldn't TTL get decremented appropriately here (and packets discarded
when it reaches 0?)
When demand exceeds link capacity long enough to fill the queue,
packets must be dropped. The traditional action of dropping the most
recent packet ("tail dropping") is no longer recommended [RED93], but
it is still widely practiced.
The reference should be to RFC 2309 and RFC2914/BCP41
A new technique called "Explicit Congestion Notification" (ECN)
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 foreseeable
future, TCP MUST interpret a lost packet as a signal of congestion.
Should reference RFC3168
work with TCP Explicit Congestion Notification (ECN) semantics
[RFC2481] [RFB01]. Routers at the edges of the subnet, rather than
shaping, would set the ECN bit in those IP packets that are received
Again, the reference should be RFC3168 (obsoletes 2481)
This archive was generated by hypermail 2b29 : Fri Feb 22 2002 - 15:05:13 EST