[e2e] Re: crippled Internet

[Vernon Schryver]

> 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