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

From: Vernon Schryver <[email-masked]>
Date: Fri, 21 Jul 2000 18:04:44 -0600 (MDT)

> From: Karl Fox <[email-masked]>

> This is last call.  I will advise the area directors that we want to take 
> Always On Dynamic ISDN (AODI) (draft-ietf-pppext-aodi-02.txt) to 
> Informational on August 18, 2000 unless there is substantive comment raised 
> on the list.

James Carlson's comments were substantive.

Jim is too polite to come out and say that AODI is mediocore or at best
unnecessary idea very poorly instantiated and designed to cause
interoperability problems, but I lack that character strength.
Advancing AODI as other than a caution of what not to do would be wrong.

The continuing danger of the IETF endorsing nonsense such as AODI and the
multi-frame thing (nonsense because it's based on the incredibly uninformed
and completely wrong notion that 14000 kbit/sec is slow for IP services)
are reasons to disband this working group.  On the other hand, if this
working group can retard some of the WAP-like publish-or-perish silliness,
maybe it should endure.

Vernon Schryver    [email-masked]

---

From: James Carlson <[email-masked]>
Date: Fri, 21 Jul 2000 22:13:05 -0400 (EDT)

> Advancing AODI as other than a caution of what not to do would be wrong.

It's awfully rare that some points me out as being polite, so, thank
you.

AODI is not merely mediocre; it intentionally breaks MP with the
unnecessary link-idle mechanism, PPP over X.25 by changing the header
format, and even tweaks BACP (which in itself is a bit of a feat).
I'm certainly happy that it's not standards-track material anymore (as
I think it was when I wrote my first comments).

I don't think AODI works as a caution.  The only substantive
discussions I had on the topic were of the form, "well, we've already
shipped it, so you can't change the design."  This model has worked
fine for RFCs 1877, 2433, and 2759 in the past, and is likely to
continue in the future.  Publishing as Informational has become, in my
opinion, an "IETF inside" ad campaign.  Some customers do realize that
it means "proprietary stuff;" most either don't or don't care.  (I
just recently had a discussion with one gentleman who had decided that
MacroMedia Flash wasn't proprietary because, well, he got it for free
and it ran on *his* PC.)

Something like AO/DI is doubtless needed for some applications, at
least until xDSL or cable access wipe ISDN from the map entirely
(which may already have happened).  It represents something that is
obsolescent enough to be not worth redesigning.  And AO/DI does
describe the solution created by one vendor.  Perhaps those factors
are enough to let it advance.

(No, before I hear about it, I'm not a marketer of ISDN equipment
anywhere, let alone in the corner of the world you call home.  Yes, it
may well be on the rise somewhere.  No, that doesn't mean that the
future for it is altogether bright.)

> and completely wrong notion that 14000 kbit/sec is slow for IP services)

There's a jello-like squishiness to this one.  Every time I talk to
someone working on the issue, the problem changes shape or moves from
one part of the system to another.  Have you seen the LIPE draft
(draft-chuah-avt-lipe-00.txt)?  This appears to be yet another
solution to the problem, and is essentially RFC 1692 TMux warmed over
and limited to just one application.

Big grain of salt here, but this is what I understand so far:

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.  This represents a
reasonably small fraction of the bandwidth of any modern modem and
shouldn't present a problem (especially with RFC 2508/2509 header
compression).

They're planning to aggregate this VoIP data from cellular base
stations over T1s back to some kind of (larger) gateway node that
converts back to regular PCM circuit-switched voice.

One of the issues is that bandwidth on the wireless side is low in
comparison to regular POTS modems.  This, I think, should be regarded
as a temporary situation and probably should not be enshrined in a
protocol.  The other is that these T1 links will (they assert) see
lots of tiny IP packets and be choked with the RTP/IP/PPP overhead.
(I don't see, though, why the same point-to-point compression won't
work there.  Figuring 8.8Kbps per call [including some PPP overhead],
you could fit perhaps 170 calls on a regular T1.  170 contexts isn't
too many to deal with.)

> working group can retard some of the WAP-like publish-or-perish silliness,

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.

All voice and no data makes johnny a dull boy.  ;-}

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

---

From: Matt Holdrege <[email-masked]>
Date: Sat, 22 Jul 2000 10:07:30 -0700

>I think it was when I wrote my first comments).

First of all, yes I moved to Informational due entirely to your comments 
about how it violates standard mechanisms. Secondly, it breaks those 
mechanisms for a reason and the resulting service does work. Thus, we are 
leaving the protocol as is for now (and likely forever giving the 
alternative access methods that have arisen to prominence recently.

>MacroMedia Flash wasn't proprietary because, well, he got it for free

There is no cure-all for ignorance. We can't stop publishing for that 
reason. What the IESG does these days is add a disclaimer to the RFC 
stating all the objections. In this case, the PPP WG has a list of 
objections which can and should be added to the resulting Informational RFC.

Why the IETF? Well the IETF is the authoritative resource for protocol 
specifications that carry IP traffic. Since this protocol doesn't meet IETF 
Standard guidelines, it is Informational. As you say, there is plenty of 
precedence and it will continue. It actually good practice despite how a 
few misapply it.

>are enough to let it advance.

True, except there is not just one, but very many vendors who support it.