Subject: LINK (Advice for Internet Subnetwork Designers)

From: "Lai, Wai S (Waisum), ALSVC" <[email-masked]>
Date: Fri, 2 Mar 2001 09:23:35 -0500

Folks,
  As DOCSIS (over cable networks) is an important subnet protocol, I propose
that the LINK document includes some discussion of aspects of the protocol.
Here's some suggested text for inclusion in the section "Choosing the MTU in
Slow Networks".  All comments are welcome.
Thanks, Waisum Lai.

Choosing the MTU in Slow Networks [Stevens94, RFC1144]

   .... (deleted)

   Another way is to implement a link-level multiplexing scheme that
   allows several packets to be in progress simultaneously, with
   transmission priority given to segments of higher priority IP
   packets. ATM (asynchronous transfer mode) is an example of this
   technique. However, ATM is generally used on high speed links where
   the store-and-forward delays are already minimal, and it introduces
   significant (~9%) additional overhead due to the addition of 5-byte
   frame headers to each 48-byte data frame.

(NEW TEXT to be inserted)
The cable-access network provides an example of using link-level
multiplexing on a slow link for accommodating interactive traffic.
Here, the upstream bandwidth, depending on the modulation format,
symbol rate, and the noise characteristics of the channel,
is typically 2.56 Mb/s or 5.12 Mb/s.   The link-layer protocol
used is Data-Over-Cable Service Interface Specifications (DOCSIS).
There are currently two versions of the protocol: DOCSIS 1.0 [1]
and DOCSIS 1.1 [2].  DOCSIS 1.0 is the original version developed
to support best-effort data service only.  The MTU is 1500 bytes.
DOCSIS 1.1 improves upon DOCSIS 1.0 by specifying an internal
fragmentation/reassembly mechanism.  Large data packets are
fragmented so that small voice packets can be sent with priority
to minimize jitter.  This works well in a pure DOCSIS 1.1 environment.
However, to accommodate the installed base, DOCSIS 1.1 must be
backward compatible with DOCSIS 1.0 cable modems, which generally
do not support fragmentation.  Under the co-existence of DOCSIS 1.0
and DOCSIS 1.1, the unfragmented large data packets from DOCSIS 1.0
cable modems may affect the quality of service for voice packets
from DOCSIS 1.1 cable modems.  In this case, it has been shown in [3]
that special bandwidth allocation algorithms can be used to mitigate
the effect.  Also, careful upstream capacity engineering is needed
since, given a number of DOCSIS 1.0 cable modems to be supported on
an upstream channel, there is an upper limit to the number of voice
sources that can be simultaneously supported on the same channel,
or vice versa.
[1] Data-Over-Cable Service Interface Specifications, Radio Frequency
Interface Specification 1.0, SP-RFI-I05-991105, November 1999,
Cable Television Laboratories, Inc.
[2] Data-Over-Cable Service Interface Specifications, Radio Frequency
Interface Specification 1.1, SP-RFIv1.1-I05-000714, July 2000,
Cable Television Laboratories, Inc.
[3] 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.

   To summarize, there is a fundamental tradeoff between efficiency and
   latency in the design of a subnetwork, and the designer should keep
   this in mind.

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Mar 2001 10:51:01 -0800

> Slow Networks".  All comments are welcome.

Can this text be condensed to its generalities? I think PILC already
deals with upstream BW and QOS issues in link design. What is the new
aspect here?

(other than be careful in your first protocol; backward compatibility
can be difficult)

Joe

---

From: Phil Karn <[email-masked]>
Date: Fri, 2 Mar 2001 12:40:00 -0800

>deals with upstream BW and QOS issues in link design. What is the new

That's exactly what I've done. My text reads:

Another 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 reassembly
procedure so that real-time voice packets can avoid undue delay when
sharing the relatively slow upstream channel of a cable modem with
large data packets.

--Phil

---

From: Phil Karn <[email-masked]>
Date: Fri, 2 Mar 2001 12:35:55 -0800

Rather than include your text as-is, I summarized your comments about
DOCSIS as follows:

I also added the three references you cited.

Phil

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Mar 2001 13:38:41 -0800

> sharing the relatively slow upstream channel of a cable modem with

Yes, but is it relevant to mention DOCSIS if this principle is more
general and already mentioned?

Lai, Wai S (Waisum) wrote:
> 
>    My purpose of introducing the text is two-fold:
> (1) DOCSIS is a widely used protocol and hence I think it should be
>     mentioned in LINK.

LINK should avoid mentioning specific link layers unless there are
general issues. Specific issues should be listed in the DOCSIS specs.

> (2) There are two aspects to DOCSIS regarding its treatment of large
>     MTU. (A) DOCSIS 1.1 uses internal fragmentation/reassembly, just
>     like other protocols.  So, in terms of protocol feature,
>     you are right that there's nothing new here, other than mentioning
>     that DOCSIS is another example.

As in "ATM and DOCSIS", but that's about it, right?

>     (B) The new twist is the need to provide backward compatibility
>     under the co-existence of both DOCSIS 1.0 and DOCSIS 1.1 where
>     some cable modems will not be able to do fragmentation.
...
>     In this case, it has been demonstrated the use of special bandwidth
>     allocation algorithm and careful capacity engineering can make it
>     to work.

Cartwheels to overcome design flaws are not necessarily techniques to
recommend. :-)

Joe