Re: [tsvwg] Request for TSVWG clue to PANRG draft author

Hi, Spencer (et al.),

AFAICT, there are a few key lessons from both IntServ and DIffServ, IMO. This isn’t a complete list, just some of the ones I’ve seen most often:

- don’t ask a question if you don’t need to know the answer
	As per Bob Briscoe, if the answer to a reservation is always “yes”, then the reservation system isn’t needed.
	The US phone system learned that it was cheaper to have enough capacity for flat-rate unlimited long distance 
	and not track than it was to operate the mechanism to track each call - the same lesson applies 

	a corollary is that it’s better to be fast than perfect, i.e., using HBH options means you should NOT expect 
	line-rate processing. frankly, it’s hard enough for vendors to keep up with line rate for all packet sizes (some don’t)
	when there are no HBH options, at least partly because consumers don’t want to pay for a feature that isn’t always
	needed (i.e., many cars have engines that work fine except for steep hills, because it’s cheaper to sell a small engine
	and most people don’t need it most of the time).

- don’t make idle threats
	Enforcement is critical; if you’re going to say no to some requests, then your system really needs to throttle those
	who either don’t bother to ask or who disregard a negative response.

- follow the money
	A mechanism that doesn’t or can’t track to billing won’t be useful. AFAICT, multicast (except for free in the local area)
	suffered from this issue - i.e., if you can’t figure out how to charge for something, how useful can it be?

- don’t read minds
	Variations in network handling of traffic should be tied to explicit markings of such, not application classes. I.e.,
	behaviors should be requested explicitly, not inferred from port numbers, etc.

Joe

> On Jul 20, 2018, at 4:04 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> 
> Dear TSVWG,
> 
> Some of you are likely aware of the Path Aware Networking Research Group (PANRG, https://irtf.org/panrg <https://irtf.org/panrg>), and some of you are likely aware that PANRG has me editing a draft on why Path-Aware Networking ideas that the IETF has considered have not been adopted, implemented, and deployed ("draft-dawkins-panrg-what-not-to-do").
> 
> There is a section on IntServ in https://tools.ietf.org/html/draft-dawkins-panrg-what-not-to-do-01#section-4.1 <https://tools.ietf.org/html/draft-dawkins-panrg-what-not-to-do-01#section-4.1>, but it seemed to me that the current contents of that section may not capture all of the reasons why IntServ was not deployed, based on TSVWG discussions at the end of yesterday's meeting session. 
> 
> If you have thoughts about that, I'd love to hear them. If you'd like to contribute on the PANRG mailing list, that mailing list is at https://irtf.org/mailman/listinfo/panrg <https://irtf.org/mailman/listinfo/panrg>. If not, unicast to me, as the draft editor, will be fine. 
> 
> And thanks for that. 
> 
> Spencer, as (in this case) individual contributor in PANRG