Subject: Re: Always On Dynamic ISDN (AODI) - Working Group Last Call

From: Vernon Schryver <[email-masked]>
Date: Fri, 21 Jul 2000 20:38:40 -0600 (MDT)

> From: James Carlson <[email-masked]>

> ...
> One of the issues appears to be that voice codecs, such as G.723.1,
> produce 20 bytes of data at (at most) about 39Hz. ...

20 Bytes/packet * 39 packets/sec = 780 Bytes/sec = 6240 bit/sec
That sounds very low, but I'm ignorant of G.723.

> ...
> I don't think this is a case of academic publish-or-perish.  This
> appears to me to be telco (wireless in particular) implementors trying
> to make an IETF-based solution that is as efficient as some
> (unmentioned) reference implementation.  That voice traffic is flat or
> declining and that data traffic now far outstrips voice in bandwidth
> seems lost as a design criterion.  If those links from the base
> stations are nearly overloaded dealing with voice and cannot tolerate
> a little extra overhead to comply with existing protocols, what will
> happen when web or video access comes to those little traffic accident
> instigators?  One tiny 50KB web page is about the same size as a
> minute of non-stop talk on VoIP.
>
> All of that is to say that there appear to be strong, application-
> dependent assumptions being made here, and that's what I think we
> should be talking about.  If the assumptions don't hold, then it
> doesn't much matter what the solutions look like.

There you go being too kind--or maybe the opposite.
I give people more credit than to really think that 14 kbit/sec is slow.

For another thing, if there really were an "(unmentioned) reference
implementation" against which the WAP-like stuff were being measured, then
it would have been mentioned after all these months.

Vernon Schryver    [email-masked]

---

From: James Carlson <[email-masked]>
Date: Thu, 27 Jul 2000 09:40:40 -0400 (EDT)

GAUCHE Francis FTRD/DAC/LAN writes:
> as we are in the D channel, layer 2 is LAPD (Q.921) and thus the
> Address field in HDLC is composed of SAPI+TEI (2 octets), and
> Control field is composed of N(S)+N(R) (2 octets). The X.25 header
> remains the same as in PPP over X.25.

This is correct.  The X.25 header is a standard and is thus always the
same and can't (reasonably) be modified by IETF documents.  The part
that's different is the payload.  For AO/DI, you don't start with the
PPP Protocol number as you should.  Instead, you start with another
(!)  HDLC Address and Control field pair and then the PPP frame
follows, starting with the PPP Protocol field.

The two are incompatible for no good reason at all.

The AO/DI draft says this:

    AO/DI recommends against header substitution by the transmitter.
    AO/DI uses the X.25 as a virtual PPP dial-up connection, so we
    recommend that the PPP header be part of the X.25 payload. This
    approach better isolates the protocol layers.

    It is desirable that X.25 receivers that expect the header
    substitution, also be able to properly function when the PPP header
    is included the X.25 payload.

The "PPP header" that the author is referring to here is actually the
standard HDLC header.  RFC 1598 says this, among other things:

      Because the Address and Control field values are not constant, and
      are modified as the frame is transported by the network switching
      fabric, Address-and-Control-Field-Compression MUST NOT be
      negotiated.

Clearly, AO/DI-speaking devices will speak a different protocol and
attempt to negotiate incompatible options with RFC 1598-speaking
devices.

Given that there's fielded equipment that understands how to deal with
Standards Track RFC 1598 encapsulation in a variety of scenarios, I
think it's misguided at best to allow subsequent drafts to modify this
procedure without at least providing some demonstrable and compelling
benefit from the modification itself.  The AO/DI draft does not do
this.

-- 
James Carlson                                  <[email-masked]>
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp

---

From: James Carlson <[email-masked]>
Date: Thu, 27 Jul 2000 11:15:55 -0400 (EDT)

GAUCHE Francis FTRD/DAC/LAN writes:
> In the X.25 payload (we usually talk about X.25 user data information field)
> you'll find the PPP frame wtih first 2 octets for the PPP protocol field
> and the following Information and Padding fields.

That's true for RFC 1598, but false for AO/DI.

> As far as i understand, this final frame (which i described in my previous
> email) looks exactly the same as the one in the RFC1598 (PPP over X.25).

It is, but only because it's not what's specified in the AO/DI draft.
The draft (and the authors, in several messages) clearly state that
the X.25 payload for AO/DI includes a second copy of the HDLC Address
and Control fields for PPP (fixed to FF 03).  This is not compatible
with RFC 1598.

> By the way, i sent 2 days ago an email with some comments on AODI draft
> (regarding Q.922/Q.921 and TEI/SAPI). I have not received a copy of this
> message on the PPP Extension mailing list (maybe that's an option and thus
> i'm not in carbon copy of my own emails sent to PPP extensions). Could you
> please tell me if you have received it ?

No.  Nor can I find any such message in the mailing list archives.