Re: new rev of LINK

[Dan Grossman <[e-mail]>]

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)