[e2e] Re: crippled Internet

[David P. Reed]

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, 
> and
> > 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 
> fragments,
> > 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

- David
--------------------------------------------
WWW Page: http://www.reed.com/dpr.html