[e2e] Re: crippled Internet
David P. Reed
dpreed at reed.com
Fri Apr 27 22:06:08 PDT 2001
Vernon, I think we are having "furious agreement" - I never said that PPP
done well was a problem, but PPP done poorly is the more common case that
people trying out VoIP see.
My point to Fred was that "people complaining about VoIP sound quality" was
a poor metric to measure network QoS if experiments are not controlled for
all the sound-quality-related problems that are endemic in the source and
destination machines and access links (down through the end-point PPP
stacks on typical commercial OS's like the Windows you hate).
I once tried (for grins) to tune another programmer's VoIP "telephone" app
running over a local 100 Mb/s network between two Windows 98 machines on
400 MHz pentiums. There was *huge* latency and jitter, but it wasn't in
the network - most of it was in the sound drivers and codecs. I reduced
jitter and end-to-end delay by a factor of 100 by writing new windows
drivers and some interrupt level kludges. But you'd never make a shippable
product that way.
At 05:02 PM 4/27/01 -0600, Vernon Schryver wrote:
> > From: "David P. Reed" <dpreed at reed.com>
> > >In my view, a reasonable PPP implementation honors the IP TOS bits as
> > >well as optionally watching for interesting UDP and TCP port number
> > >and might even move small packets to the front of the transmit queue,
> > >and so gives low-latency traffic delays as good as possible.
> > PPP's lack of implementing such features introduces unnecessary jitter,
> > this why my point. And if done properly, PPP on a bottleneck link (like a
> > 56 Kb modem's 33 Kb uplink) would chop elephants into link-level
> > so priority datagrams would preempt FTP packets of 500 bytes or so (a
> > significant jitter can be induced at today's access link speeds).
> > What PPP implementations honor TOS bits today, and what VoIP sources
> > actually set the TOS bits?
>What does this have to do with RFC 1661? It's important to not let
>the major problems in VoP be blamed on red herrings like "PPP". I've
>spent too many years listening to marketeers blame the market failures
>of desktop VoIP and video conferencing on "PPP" to let it pass here.
>I doubt the PPP implementation I wrote for Silicon Graphics in the 1980's
>has lost TOS queuing. I think many other implementations had it as well,
>but I can't speak for them. It's only about 20 lines to implement in a
>BSD "if" style driver, including protecting elephants from starvation.
>SGI's video conference application of almost the same age used 300 byte
>UDP/IP packets, set the IP TOS bits, and liked to set the PPP MTU to 300
>for that elephant problem, but I suspect that application is moribund.
>Anyone writing latency sensitive applications for UNIX systems and who
>does not RTFM or at least crib the setsockopt(,IPPROTO_IP,IP_TOS,) from
>the many years-old 4.4BSD telnet/commands.c is not showing much interest
>in doing a good job. I think that setsockopt() fell out of Winsock
>between 1.0 and 2.0, but what Microsoft does is not always proof of much
>of interest. But what does that have to do with PPP?
>Anything more than TOS marking by applications is irrelevant to VoIP
>over modems. As you almost said explicitly, a "56K" modem is really
>more of a 15-30 Kbit/sec modem, since both directions matter. I
>suspect any traffic in addition to VoIP packets is very bad at such
>low rates, unless you use encodings that are rather different from
>"toll quality." Perhaps at 128 kbit/sec you'd still want to chop 1500
>byte=94 ms FTP packets, but at 500 kbit/sec you're only talking about
>24 ms/link. And again, the cleanest way to do that is the local
>equivalent of adding "MTU 300" or 500 to your ifconfig command, which
>still has nothing to do with the Point to Point Protocol.
>For DSL or cable modem service, if you didn't use the abomination that
>is PPPoE and so didn't have PPP involved, what would you kick around
>instead? There are more than enough warts on PPP without making it the
>whipping boy for every bad implementation of anything vaguely related
>serial links. (e.g. silly, do-nothing-but-add-bugs marketing protocols
>like BACP, interesting extensions by Microsoft, years of delay on
>compression by the IESG and then the industry settling on lamo STAC,
>failures by major access router vendors to get even STAC right, near
>universal failure by access router vendors to support VJ header compression
>and so save 40 bytes/packet, the mess that is L2TP, and on and ...)
> > I'm much more dubious that PPP should read
> > magic port numbers (especially since RTP can't be identified by port
> > numbers in packets).
>Yes, today watching port numbers is not very compelling. Compared to
>my kludge of moving all small packets to the front, Van Jacobson's
>mechanism of noticing interesting ports like 23 and 513 is squeaky
>clean and lacking side effects.
>Vernon Schryver vjs at rhyolite.com
WWW Page: http://www.reed.com/dpr.html
More information about the end2end-interest