Subject: Re: Comments to "Advice for Internet Subnetwork Designers"

From: Vernon Schryver <[email-masked]>
Date: Fri, 21 Jul 2000 09:55:28 -0600 (MDT)

> From: Reiner Ludwig <[email-masked]>

> ...
> I didn't write that they were "*new* DS Field values". I explicitly wrote 
> that I borrowed from RFC1349 (Type of Service).
>
> >This is not at all what I was talking about.
> >The service classes you discuss can be adequately supported using
> >the existing PHBs
>
> Maybe I missed something.
>
> How can you specify with the existing DSCPs/PHBs that a flow (more 
> precisely the application on top) is best served with max throughput and 
> max reliability?

As you wireless people keep pointing out, you can't maximize both
simultaneously without failing to maximize one or the other.  Do you mean
to maximize throughput or queue position compared to competing traffic
but to not turn off link layer forward error correction or error detection
and retransmission?

> >(and indeed, Diffserv has always clearly stated that
> >PHBs/DSCPs do not represent e2e service classes as classically
> >understood).
>
> I didn't say anything else. I only said that I wished that such e2e service 
> classes could be defined. As it was possible with the TOS byte.

If the people running the edges where the new DS bits are changed
do stupid things, then bad things will happen to the applications that
rely on the new DS bits, or at least they not use the new DS bits.

And in turn, that make make people working on modern wirelss links do as
others did, those who worked on links with bit error rates as bad as modern
wireless links but with speeds 10 times slower than modern wireless links.
1200 bit/sec modems were slow, and they had lots of bit errors.  In not
so ancient days, many people turned of v.42 over v.32 modems.

Those old techniques, besides honoring the IP TOS byte, included assuming
that small packets need lower latency and peeking at UDP and TCP port
numbers.  I've personally written, used, and caused to be shipped users
of a what was once a major UNIX vendorcode that does all three.  I think
Van Jacobson's port snooping queuing is in a vast number of installations.

Vernon Schryver    [email-masked]

---

From: Reiner Ludwig <[email-masked]>
Date: Mon, 24 Jul 2000 12:16:36 +0200

At 09:55 21.07.00 -0600, Vernon Schryver wrote:
>simultaneously without failing to maximize one or the other.

Don't agree with you here.

>Do you mean

Nothing about qeue position and nothing about competing traffic, i.e., 
nothing about scheduling.

But, I can run my wireless link with maximum error recovery persistency 
(i.e., max reliablity) but with FEC A for telnet to minimize delay and FEC 
B for ftp to maximize throughput.

>rely on the new DS bits, or at least they not use the new DS bits.

Exactly, and that's the problem I see. Again, I wish we could have DSCPs 
with e2e semantics.

>Van Jacobson's port snooping queuing is in a vast number of installations.

True many SLIP and PPP implementations play these tricks. As I said in an 
earlier mail, the problem with sniffing tricks is IPsec which is important 
for many wireless users/operators. Such users easily trade security for 
performance. Too bad because we could have both if we did it right.

///Reiner