Re: new rev of LINK

[Gorry Fairhurst <[e-mail]>]

Dan, see some in-line comments, but mostly agree with you.

Dan Grossman wrote:

Gorry
-------------
> 
> 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.
> 
--GF: It says "was", and so seems true still to me...
>    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]." 
--GF: Yes, this seems fair.

> 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.
--GF: I don't think we should remove it.  The reason for saying this was
-- to alert the reader that these were an IMPORTANT part of the design.
-- maybe yoyu should delete "though" which kinds of suggests these
-- are peripheral elements!

> 
>    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,..."
--GF: add "1-bit ATM User-User Indication" and I'd be very happy with this
> 
>    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.
--GF: Yes, I think this has become garbled, agree delete it.

> 
>    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.
--GF: OK.
> 
>    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.
--GF: seems good.

> 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?

--GF: I would say DOCSIS uses BoD, it's packet-by-packet or once per
--few RTT capacity management... SVCs are once per "connection" assignment
--as a rule. That's different
> 
> 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.
> 
--GF: Suggest we drop the preface. and start with "FEC is now nearly"

>    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?)
--GF: I guess according to some RFC authors....but how much of this is
-- is atually done. TTL doesn't map to time anymore - if it ever did!
> 
>    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)
--