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

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 20 Jul 2018 06:04:57 -0500

Dear TSVWG,

Some of you are likely aware of the Path Aware Networking Research Group
(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,
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. 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

---

From: Joe Touch <[email-masked]>
Date: Fri, 20 Jul 2018 08:00:20 -0700

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 <[email-masked]> 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. 
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 20 Jul 2018 10:16:49 -0500

Hi, Joe,

On Fri, Jul 20, 2018 at 10:00 AM Joe Touch <[email-masked]> wrote:

> 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:
>
> 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
> Enforcement is critical; if you’re going to say no to some requests, then
> your system really needs to throttle those
> A mechanism that doesn’t or can’t track to billing won’t be useful.
> AFAICT, multicast (except for free in the local area)
> Variations in network handling of traffic should be tied to explicit
> markings of such, not application classes. I.e.,

Thanks, this is very helpful!

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Jul 2018 05:41:29 +1200

Joe,

I agree with all that, but I'd like to explore one point a bit further:

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

I heard the opposite assertion yesterday: that we can now build
hardware that's fast enough to handle state lookup and header
processing per packet at line speed.

Now Moore's law etc. has indeed meant that lookup and processing
have been getting faster over many years, but so has line speed.

My question is: has anybody systematically studied whether the
increase in state lookup and processing speed has kept up with
or exceeded the increase of line speed, all at constant real
cost per customer?

If lookup and processing speed has *not* increased significantly
faster than line speed, at constant cost per customer, I don't see
how solutions requiring per-flow state can succeed any better than
RSVP.

We know that with powerful enough rockets, pigs can fly, and
carrier-grade NATs can handle per-flow state, but I very much
doubt that this meets the standard of constant cost per customer
compared to stateless forwarding.

Does anybody have numbers or can point to a published study?

Regards
   Brian

---

From: Joe Touch <[email-masked]>
Date: Fri, 20 Jul 2018 10:51:23 -0700

Hi, Brian, 

I take your point that hardware has gotten faster, but AFAICT it will
always be cheaper to not process HBH options in hardware. 

The real question will be whether anyone will want to pay what HBH
hardware costs for the benefit/revenue possible, e.g., for QoS -- again,
vs. just over provisioning capacity. 

Though I too would be glad to hear what's possible (esp. if it can
include some hint at the relative cost). 

Joe

On 2018-07-20 10:41, Brian E Carpenter wrote:

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

---

From: Tom Herbert <[email-masked]>
Date: Sat, 21 Jul 2018 10:33:53 -0700

On Fri, Jul 20, 2018 at 10:51 AM, Joe Touch <[email-masked]> wrote:
> Hi, Brian,
>
> I take your point that hardware has gotten faster, but AFAICT it will always
> be csheaper to not process HBH options in hardware.
>
Joe,

The answer to this depends on the exact question being asked. If the
question is whether hardware can process any arbitrary number and
combination of TLVs in HBH options as allowed by standard, then the
answer will be no. For instance, it's unreasonable to a expect anyone
to efficiently parse a long list of tiny TLVs with random unknown
types whose number in the packet is only limited by MTU (could be
hundreds of them in a single packet)

However, if the question is whether hardware could parse HBH options
that are somehow constrained, like maybe only needing to parse a
couple of TLVs that are known to the implementation, fixed length, and
the total length keeps all headers within the parsing buffer of HW
(typically 128 bytes currently); then procesing HBH options in HW
could be feasible.

> The real question will be whether anyone will want to pay what HBH hardware
> costs for the benefit/revenue possible, e.g., for QoS -- again, vs. just
> over provisioning capacity.
>

Programmable hardware devices, like those that support BPF or P4,
should address the cost component of the problem.

Tom

> Though I too would be glad to hear what's possible (esp. if it can include
> some hint at the relative cost).
>
> Joe
>
>
>
>