Subject: [Stackevo] RFC 4594bis (was: Next steps: Stack Evolution Program communication on traffic characterization)

From: "Black, David" <[email-masked]>
Date: Sat, 28 Nov 2015 21:10:47 +0000

I'm quoting a few sentences from Brian in order to talk about some rather relevant
related work:

> The transport layer needs no semantic information about the content whatsoever.
> All it needs to know are how fast the packets are going to come, and how relatively
> bad it is to delay or drop them. Extra semantics about the application add risk
> for no additional utility here.

+1, and moreover, the IETF has already done significant prior work in this area,
as recorded in RFC 4594 on Diffserv Service Classes (aka traffic classes):

	https://datatracker.ietf.org/doc/rfc4594/

In particular, sections 2.2 and 2.3 and the tables therein are relevant to this
discussion, which is effectively about traffic classes and how the network should
treat them when resources are not unlimited (which is almost always the case).

The reason for bringing up RFC 4594 here and now is that it appears likely that the
TSVWG working group will make minor revisions to RFC 4594 and ask for the result to
be published as a BCP, as RFC 4594 has effectively been a BCP for Diffserv deployment
for a number of years (and there are a number of minor things in it or omitted from
it that need attention).  This will take a while - a year from now would be an
optimistic guess (IMHO) for when the WG activity on 4594bis might complete w/a
publication request to the IESG.

That leads to a couple of suggestions:

- Start from RFC 4594's traffic class characterizations, not from scratch.
- The default DSCP (or PHBID, see RFC 3140) is one place to look for bits to expose
	to help the network figure out what to do when the going gets tough.

The latter seems like a much better place to start than the (well-intentioned, IMHO)
MaRNEW suggestion of a 1 bit (Zero / One bit for latency bandwidth tradeoff).  That
one bit will inevitably be insufficient, and the resulting scope expansion will head
into the general area of QoS that contains RFC 4594.

That said, the DSCP field in the IP header is unusable for the purpose being
discussed here because that field is not end-to-end; in fact there's a common
practice of "bleaching" that DSCP field to zero (best effort) at network boundaries
for operational reasons, so we'd need to look at a new signaling mechanism of some
form (e.g., SPUD would be among the possibilities).

Thanks,
--David

> -----Original Message-----
> From: Stackevo [mailto:[email-masked]] On Behalf Of Brian Trammell
> Sent: Tuesday, November 24, 2015 1:22 AM
> To: Eliot Lear
> Cc: Stackevo; Russ Housley; [email-masked]; IAB
> Subject: Re: [Stackevo] [Privsec-program] [IAB] Next steps: Stack Evolution
> Program communication on traffic characterization
> 
> hi Eliot,
> 
> > On 23 Nov 2015, at 21:04, Eliot Lear <[email-masked]> wrote:
> >
> > Hi Brian,
> >
> > Thanks for your response.  I'm particularly impressed with your extensive
> elaboration on an iPhone ;-)  And I feel especially bad about that given what
> I'll say below.
> >
> > On 11/23/15 8:39 PM, Brian Trammell wrote:
> >
> >> To be minimalist, let me suggest dropping the word "irrelevant".  It may be
> very relevant, both to transport as well as, say, implementation cybersecurity
> (to name but another example).
> >>
> >> So this gets to the crux of the matter: there is a always a risk-utility
> tradeoff here, and the evaluation of utility is specific to the task. Legal
> intercept, certain security monitoring techniques, tools trying to audit
> applications' radiation of private data all require access to content, of
> course, so not only is all metadata relevant, all data is, too. Most tasks
> that have something to do with the popularity of content (advertising and
> distribution) at least need content identity.
> >>
> >
> > Yes.
> >
> >> But for the task of effectively managing transport-layer interactions (and
> assumptions the link layer makes about what it can know about the transport
> layer, which is what we're talking about here), I'm going to push back on
> this. The transport layer needs no semantic information about the content
> whatsoever.
> >
> > I mostly agree.  The corner case has to do with codecs, which are weird
> things (at least to me) that have very transporty aspects.
> 
> Okay, that's a valid point.
> 
> > And that was the example at hand.
> 
> Yep... it was a bad one, although in many applications, there's still a
> component between the encoder and the sender that can change the shape of the
> traffic (think adaptive bitrate streaming). For interactive video, the codec
> *does* need be closer to the wire for good results.
> 
> Video service ("this is YouTube") is a more illustrative example of the type
> of less relevant metadata I'm thinking of here. Classification of this type
> conflates the transport characteristics ("traffic with whatever shape YouTube
> has this year") with others ("a website with rlarge amounts of user-generated
> content")
> 
> >   But I don't have the context about MarNEW to know whether or not the other
> stuff above is or is not relevant.
> >
> >>  All it needs to know are how fast the packets are going to come, and how
> relatively bad it is to delay or drop them. Extra semantics about the
> application add risk for no additional utility here. Identifying these by
> underlying content type ("YouTube video", for example, is one almost universal
> identifier coming out of current DPI systems for traffic management as I
> understand it) is (1) an artifact of the implementation used to classify the
> traffic and (2) deceptively human-readable but (3) doesn't actually tell the
> network elements what is expected of them.
> >>
> >>
> > This holds true so long as the behaviors are optimal for codecs, that is
> fine.  I can't answer that question; perhaps others can.  I know that Al
> Norton has done a LOT of work on that...
> 
> I'll ping Al.
> 
> > I also want to point out that something can be relevant and wrongheaded ;-)
> 
> Indeed. What I'd like to do here is use the fact that encryption will wreck
> the current way of doing things issue a challenge to be less wrongheaded when
> designing the next one.
> 
> Thanks, cheers,
> 
> Brian
> 
> > Eliot
> >
> > _______________________________________________
> > Privsec-program mailing list
> > [email-masked]
> > https://www.iab.org/mailman/listinfo/privsec-program

---

From: Brian Trammell <[email-masked]>
Date: Mon, 30 Nov 2015 12:27:41 +0100

hi David, all,

Thanks, responses inline...

> On 28 Nov 2015, at 22:10, Black, David <[email-masked]> wrote:
> 

Thanks for the pointer. This is quite useful, in that tables 1 and 2 map the classes into three axes of tolerance and one axis of elasticity (in which I count about six bits of information, yay efficiency!). I think the *labels* on these traffic classes are probably less useful, in that they are defined in terms of application semantics instead of network treatment, but that's probably a more philosophical argument.

> into the general area of QoS that contains RFC 4594.

So there's a very nice property that the one bit for latency tradeoff proposal has, and that's the word "tradeoff". I don't see many tradeoff pairs in 4954, which might explain why there's a lot of bleaching: the missing tradeoff axis in an interdomain context is settlement. In theory, I mark Telephony, and I pay you for it. I mark Low-Prio Data, and you count those bits less as part of my 95th. (Does anyone actually do this?)

In terms of table 2, "latency sensitive" would be High / Low / Undefined (for Loss/Latency/Jitter tolerance), and "loss sensitive" would be Low / High / High. I note that the "loss sensitive" point matches most properly High-Throughput Data, which is intuitively satisfying, but that there is no 4954 point for "latency sensitive". I cannot use DSCP to signal that I am willing to eat loss to reduce latency, so I think the one bit proposal is a fundamentally different thing from DSCP.

There are definitely lessons to be learned (e.g. elasticity is a potentially useful axis to signal), and I very much appreciate the warning that starting off with one bit might lead to us reinventing DSCP, and we really shouldn't do that. But I'm not sure DSCP is a useful starting point if we want to be open to ending up in a place that isn't basically DSCP.

Cheers,

Brian

---

From: Eliot Lear <[email-masked]>
Date: Mon, 30 Nov 2015 13:00:55 +0100

Right.

What I liked about Al Norton's work in SG12 at the ITU was that they did
something that cut across SDOs (IEEE and IETF in particular).  Once
again, so long as the network behavior can adequately meet the needs of
the applications, and so long as applications can adequately express a
desired network behavior, all of this works.

Test 1: is there a real world application that is not able to
sufficiently describe its needs to the network?

That then turns us to trust models, by the way.  Were they discussed at
MarNEW?

Eliot