Subject: draft-ietf-pppext-aodi-01.txt

From: Jonathan Goodchild <[email-masked]>
Date: Tue, 29 Jun 1999 16:34:52 +0100

A few comments:

From Page 3:

>    The IETF provides some guidelines for the use of PPP over X.25 in
>    RFC 1598.  Strictly speaking, RFC 1598 does not apply to AO/DI, but
>    it has been used as a source of many useful concepts.

(It seems to me that had RFC 1598 been written properly, then it ought
to apply equally to X.25 over the ISDN D channel. Perhaps RFC 1598 ought
to be updated during the current phase of document maturation, although
I notice that it's not mentioned in the list of working group
milestones.)

>    It is believed that the overhead of two bytes is more than
>    compensated by the fact that any link in AO/DI could now be treated
>    as dial-up PPP connection due to the protocol stack layering that
>    resulted; i.e., the same PPP process is used for B-Channels and the
>    X.25 channel.

This seems sensible, but an explicit description of the "overhead" might
be useful to avoid any confusion.

>The Data Link Layer
>
>    From RFC 1598: Since both "PPP in HDLC Framing" [3] and X.25 use
ISO
>    3309 as a basis for framing, the X.25 header is easily substituted
>    for the smaller HDLC header.  The fields are transmitted from left
>    to right.
>
> 0                   1                   2                   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>+-+-+-+-+-+-+-+-+
>|  Flag (0x7e)  |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|    Address    |    Control    |D|Q| SVC# (hi) |   SVC# (lo)   |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|p(r) |M|p(s) |0|         PPP Protocol          |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This description of the framing is misleading - there are 2 octets in
the address field in Q.922 (as opposed to 1 in X.25 LAPB).  Also (my
memory may be wrong here), but isn't the control field 2 octets as well?
It certainly is for SAPI 0 (as used by Q.931 for ISDN call setup).

In addition, having the PPP Protocol field follow immediately after the
X.25 Packet header seems to contradict the previous paragraph about the
"two byte overhead", which I had assumed to be the PPP frame's address
and control field.

Anyway, I consider this description of the framing (and the one in RFC
1598) less than
useful, especially as it ignores the existence of the X.25 M bit - as
far as the PPP implementor is concerned, there is no need to know about
the X.25 protocol frame and packet headers at all.  A PPP implementor
just needs to know how to encapsulate the PPP packet within an X.25
"complete packet sequence" (as defined by X.25 clause 4.3.5).  I
therefore think it's better to omit the framing diagram entirely.  A
diagram of the PPP encapsulation might be useful, although it ought to
be the same as the one in RFC 1661.

(A problem of RFC 1598 is that it takes no account of the possibility of
modulo 128 sequence numbers, which alter the size of the X.25 headers.
I assume that as far as AO/DI is concerned, modulo 8 is always used by
the X.25 packet layer.)

On a more trivial note, what does the term "PC" mean as used in the
draft? For example, in the following paragrap on page 3:

>    * Inability to contact the subscriber.  This could be due to the PC
>    being turned off, an equipment problem due to hardware or software
>    in the network or the PC, etc.

If it means Personal Computer, I would have thought that a more general
term for the user's terminal would be more appropriate.  Or is AO/DI
aimed only at PC's?

Out of curiosity, why is MP+ listed in the references?  I couldn't find
a reference to it in the text.

There also appear to be a number of typos.

In the following paragraph on page 3, "it's" should be "its".

>    * The success of X.25 networks was due in part to the use of SVCs
>    and the ease of provisioning.  Frame Relay, although successful, is
>    extremely complex to provision because of it's PVC implementation
>    and the same would apply to a managed service provider solution.

On page 7, there seems to be an inconsistent use of the singular and
plural in the following paragraph:

>    This recommendation makes it possible for users to operate AO/DI
>    capable protocol stacks even when the users ISDN network interface
>    card does not support AO/DI, or if the user does not have an AO/DI
>    service due either to lack of facilities at the users ISP and/or at
>    the LEC.

How about:

    This recommendation makes it possible for a user to operate AO/DI
    capable protocol stacks even when the user's ISDN network interface
    card does not support AO/DI, or if the user does not have an AO/DI
    service due either to lack of facilities at the users ISP and/or at
    the LEC.

On page 11, "users" should be "user":

>    * When looking at Web pages, a good activity timer is 5-10 seconds
>    without activity probably means the users is studying the received
>    materials and will be absorbed for several tens of seconds longer.

Page 14, "CVD" should be "CUD":

>    * CVD up to 16 octets in length

Page 15, "through put" should be "throughput"

>    When bandwidth becomes insufficient, AO/DI attempts to augment the
>    bandwidth.  Failure to augment bandwidth results in continuing with
>    a slower-than-desired throughput, but no damage.  If the D-Channel
>    through put becomes unacceptable, an attempt to add a B-Channel
will
>    be made; this could be the result of delays in packet
acknowledgment
>    or even packet rejection at the packet handler.

Jonathan Goodchild
FarSite Communications Ltd
email: [email-masked]