Subject: new rev of LINK

From: Mark Allman <[email-masked]>
Date: Tue, 19 Feb 2002 23:22:30 -0500

Folks-

I just sent the secratariet a new version of LINK.  Some notes...

  * See http://roland.grc.nasa.gov/~mallman/share/link/ for the
    latest rev, as well as diffs and word diffs since the last
    version.  I also included the last version in that directory as
    well so that you can use whatever sort of differ you like best.

  * The author list has been trimmed because the RFC editor is no
    longer publishing RFCs with more than 5 authors.  This seemed
    like the fairest approach.  (Authors -- err, former authors --
    have been notified under seperate cover, as well.)

  * The fixes between this version and the last....  nits all over
    the place.  The CRC section has been overhauled (Gorry and
    Lloyd).  The broadcast and multicast sections have been reworked
    a little (Gorry) and moved within the document.  Finally, I
    tried to hack at the BoD section a little.  

  * Please check the document to make sure I included your
    comments.  There is a decent chance that I something could have
    been dropped on the floor in the handoff between Phil and I.

  * I plan to issue another rev of this document on 3/1 (the
    deadline for Minneapolis).  In the next week and a half people
    should read the document to make sure it is in good shape and
    that I have included all the fixes that I am supposed to have
    included.  After 3/1 the chairs will issue another WG last call
    for the document (likely to be short given that we have already
    gone through one).  And, then it is off to the IESG for this
    doc.

Send heartburn if you've got it.  And, quick.

Thanks,
allman

---
Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/

---

From: Dan Grossman <[email-masked]>
Date: Fri, 22 Feb 2002 15:01:18 -0500

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)

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 25 Feb 2002 13:37:16 +0000

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

Dan Grossman wrote:

Gorry
-------------
> 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...
> Service Interface Specification (DOCSIS) version 1.1 [DOCSIS2]." 
--GF: Yes, this seems fair.

> By 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!

> the ATM User-User Indication, which is encoded in the Payload Type field
--GF: add "1-bit ATM User-User Indication" and I'd be very happy with this
> Not true.  The HEC covers the entire cell header.  Delete the
--GF: Yes, I think this has become garbled, agree delete it.

> placed.  Suggest removing this.
--GF: OK.
> Or words to that effect.  You might even want to move that last bit up a
--GF: seems good.

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

--
> Shouldn't TTL get decremented appropriately here (and packets discarded
--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!
--
--
--

---

From: Dan Grossman <[email-masked]>
Date: Mon, 25 Feb 2002 11:53:07 -0500

Gorry,

> --GF: It says "was", and so seems true still to me...

I hope we're not going to play semantic games with the meaning of "was" and
"is".  We impeached a President over here for doing that :-).  If you read the
draft, the message from the IAB is that end-to-end is an ideal, but the
reality is not the ideal.  I'm sure Mark can come up with words that are
politically correct and more accurately reflect the reality of the Internet.

> -- are peripheral elements!

It seemed out-of-context as well.  I'll leave that to Mark.

> --GF: add "1-bit ATM User-User Indication" and I'd be very happy with this

Except that it's not encoded as one bit!  Two of the eight values of the field
indicate "AUU == FALSE" and two indicate "AUU == TRUE".  The remaining
encodings indicate things that are completely different (like "I'm an
end-to-end OAM cell", and "I'm a resource management cell").  Try:.."... which
is encoded as a binary value in the Payload Type field of an ATM user data
cell,..."

> --as a rule. That's different

So the defining characteristic of  BOD is that it does resource assignments
per burst, and the resource can't be held longer than a burst?

> -- is atually done. TTL doesn't map to time anymore - if it ever did!

It's got multiple personality disorder for sure... but I believe that RFC1812
is pretty specific about when to use it as a timer.

rgds
Dan.

---

From: Joe Touch <[email-masked]>
Date: Mon, 25 Feb 2002 10:21:37 -0800

> I'm mostly ok with this, but:
...

> is pretty specific about when to use it as a timer.

Unfortunately (from 1812):

	When a router forwards a packet, it MUST reduce the TTL
	by at least one. If it holds a packet for more than one
	second, it MAY decrement the TTL by one for each second.

The MAY kills using it as a timer at all :-)

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 25 Feb 2002 18:36:11 +0000 (GMT)

> The MAY kills using it as a timer at all :-)

(not following this thread in detail, sorry)

note that the definition of hop limit for IPv6 in RFC2460 is explicit.
mapping TTL to time in ms is quite simply unworkable in routers.

but ttl decrementing (and IPv4 header checksum recalculation) is very
much an IP-level function, and something to do on egress from the
router, not ingress from a link.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Dan Grossman <[email-masked]>
Date: Mon, 25 Feb 2002 13:58:34 -0500

Oooops... I misremembered the "MAY" as a "MUST".   Now I'm curious.  Does anybody
on the list happen to know why it's not a "MUST" or a "SHOULD"?

---

From: Joe Touch <[email-masked]>
Date: Mon, 25 Feb 2002 11:39:22 -0800

> on the list happen to know why it's not a "MUST" or a "SHOULD"?

It's in RFC1812, later on in the same section on TTL:

  	 In this specification, we have reluctantly decided to follow
          the strong belief among the router vendors that the time limit
          function should be optional.  They argued that implementation
          of the time limit function is difficult enough that it is
          currently not generally done.  They further pointed to the lack
          of documented cases where this shortcut has caused TCP to
          corrupt data (of course, we would expect the problems created
          to be rare and difficult to reproduce, so the lack of
          documented cases provides little reassurance that there haven't
          been a number of undocumented cases).

Joe