Re: [Accord] presentation slot for draft-you-tsvwg-latency-loss-tradeoff

[Brian Trammell <[e-mail]>]

hi David,

Thanks -- we'll discuss in ACCORD, continue discussion on the tsvwg list, and should it make sense, bring something to tsvwg in Berlin. One comment below...

> On 30 Mar 2016, at 15:31, Black, David <[e-mail]> wrote:
> 
>>> Lo and La are defined such that there is an *explicit tradeoff*. The hope is that
>> by putting these new codepoints in part of the code space that is always subject
>> to these explicit tradeoffs -- marking Lo or La need not disadvantage DF -- makes
>> it possible to bleach the existing DS architecture codepoints, which are used
>> internally but cannot deploy in the general interdomain case due to mark
>> inflation, while passing the interdomain-friendly tradeoff-based codepoints,
>> which are defined such that there is no incentive for mark inflation.
> 
> The Diffserv-Intercon draft (draft-ietf-tsvwg-diffserv-intercon) is trying to do something
> better than bleaching all existing codepoints, but it is still contract-based.

Which is the right way to do it, IMO. You *do* need to be able to do QoS where the tradeoffs aren't explicit. The one bit latency tradeoff and other DSCP applications shouldn't be mutually exclusive. Unfortunately, there's only one six-bit field in the IP header, unless you put the tradeoff bits somewhere else. (On which, see section 5.2 in draft-kuehlewind-spud-use-cases :) ).

Cheers,

Brian

> Looking at the ACCORD BOF goals:
> 
>>> Broadly speaking, there are two things I hope we accomplish with the ACCORD BoF:
>>> 
>>> (1) Have a discussion about how radio access networks (RAN) work, and how
>> this architecture doesn't fit with common IETF perceptions about what happens
>> at layer 2.
>>> 
>>> (2) Determine the minimum set of information that RAN schedulers actually
>> need (i.e., in deployed networks, not in the 3GPP architecture) about application
>> traffic to function correctly in the absence of traffic classification provided by DPI.
>>> 
>>> We believe the loss-latency tradeoff bit to be a potential (partial) solution to
>> the problem in (2), given how few different classes of traffic seem generally to be
>> deployed.
> 
> It feels like the discussion in Buenos Aires ought to start in ACCORD, which is
> (unfortunately) scheduled for Thursday, after the TSVWG sessions on Tuesday
> and Wednesday.  I think it would be better for the problem discussion in ACCORD
> to precede any TSVWG discussion of solution mechanics, so I'd lean against doing
> anything in the TSVWG meetings next week aside from bringing attention to
> the ACCORD meeting and discussion expected to occur there.
> 
> Longer-term, I absolutely concur that TSVWG is the right home for Diffserv work,
> but ACCORD seems like the right place in Buenos Aires to better understand the
> problem to be addressed.
> 
> Thanks, --David
> 
>> -----Original Message-----
>> From: Gorry Fairhurst [mailto:[e-mail]]
>> Sent: Tuesday, March 22, 2016 1:33 PM
>> To: Brian Trammell
>> Cc: Black, David; [e-mail]; draft-you-tsvwg-latency-loss-
>> [e-mail]; [e-mail]
>> Subject: Re: presentation slot for draft-you-tsvwg-latency-loss-tradeoff
>> 
>> On 22/03/2016 13:50, Brian Trammell wrote:
>>> hi Gorry,
>>> 
>>>> On 22 Mar 2016, at 10:23, [e-mail] wrote:
>>>> 
>>>> 
>>>> I'm not finding this ID very easy to get into... and I think there may be
>>>> various reasons, but I suspect David may be digging in a good place to
>>>> start.
>>>> 
>>>> This looks and feels like a -00 draft.
>>> 
>>> As indeed it is. :)
>>> 
>>>> From the current, I still need to
>>>> understand why the code points would be needed and why new ones would
>>>> help.
>>> 
>>> Quoting myself, below:
>>> 
>>>>> ... it really does seem to be that all existing
>>>>> Diffserv PHBs have shown themselves to be irrelevant for the case we are
>>>>> addressing here -- applications on the content side signaling loss/latency
>>>>> tradeoffs to access networks across the open Internet.
>>> 
>>> 
>>>>> The reason to ask for new codepoints is to make it *possible* to continue
>>>>> blocking all existing PHBs while not bleaching PHBs that are not tied in
>>>>> any network (whether by definition or by local configuration) to a request
>>>>> for "better" treatment. A firewall rule could be configured to pass La and
>>>>> Lo (along with other potential future explicit-tradeoff codepoints) while
>>>>> still bleaching other PHBs to DF.
>>> 
>>> 
>>> To elaborate:
>>> 
>>> Every marking other than DF is an explicit request for treatment which will
>> disadvantage DF traffic. There is no mechanism for tradeoff in the DS architecture
>> outside legal contracts between two directly connected networks, which limits its
>> deployability in the general (interdomain, open-Internet) case.
>>> 
>>> Lo and La are defined such that there is an *explicit tradeoff*. The hope is that
>> by putting these new codepoints in part of the code space that is always subject
>> to these explicit tradeoffs -- marking Lo or La need not disadvantage DF -- makes
>> it possible to bleach the existing DS architecture codepoints, which are used
>> internally but cannot deploy in the general interdomain case due to mark
>> inflation, while passing the interdomain-friendly tradeoff-based codepoints,
>> which are defined such that there is no incentive for mark inflation.
>>> 
>>> This is, I admit, perhaps laughably optimistic. But it would allow the treatment
>> to deploy on current hardware, as DSCP-aware boxes can already make
>> forwarding and queueing decisions based on DSCP codepoints.
>>> 
>>>> I think previous experience in TSVWG suggests a lack of precise
>>>> language can surely end with rathole discussions.
>>>> 
>>>> I can see value in a heads-up for people who know and care about Diffserv
>>>> deployment to be encouraged to show-up at ACCORD.
>>> 
>>> Yes, please. :)
>>> 
>>>> However, I continue to be really confused about which drafts may be linked
>>>> to the ACCORD BOF, and what this could lead to, that doesn't stop me
>>>> thinking that the BoF could be a good place to start discussion.
>>> 
>>> Broadly speaking, there are two things I hope we accomplish with the ACCORD
>> BoF:
>>> 
>>> (1) Have a discussion about how radio access networks (RAN) work, and how
>> this architecture doesn't fit with common IETF perceptions about what happens
>> at layer 2.
>>> 
>>> (2) Determine the minimum set of information that RAN schedulers actually
>> need (i.e., in deployed networks, not in the 3GPP architecture) about application
>> traffic to function correctly in the absence of traffic classification provided by DPI.
>>> 
>>> We believe the loss-latency tradeoff bit to be a potential (partial) solution to
>> the problem in (2), given how few different classes of traffic seem generally to be
>> deployed.
>>> 
>>> Cheers,
>>> 
>>> Brian
>>> 
>>> 
>>>>> Hi, David,
>>>>> 
>>>>>> On 21 Mar 2016, at 04:07, Black, David <[e-mail]> wrote:
>>>>>> 
>>>>>> I'd think that this draft is also planned for presentation in the ACCORD
>>>>>> BOF - how is the discussion in TSVWG expected to differ from ACCORD?
>>>>> 
>>>>> In ACCORD, we're planning very short "here's what Lo and La mean, we have
>>>>> a draft that defines Lo/La-over-DSCP, we also have a use case (in
>>>>> draft-kuehlewind-spud-use-cases) for Lo/La-over-SPUD". The presentation
>> in
>>>>> TSVWG would get into the details of why we think we need new DSCP
>>>>> codepoints for this.
>>>>> 
>>>>> If we assume everyone who might be interested in this will be in ACCORD
>>>>> anyway, we can compress our discussion of "why do we need new
>> codepoints"
>>>>> into that single presentation.
>>>>> 
>>>>>> I'm concerned about the draft's brief dismissal of each existing
>>>>>> Diffserv PHB as irrelevant with very little explanation.
>>>>> 
>>>>> As am I. But I personally consider that a problem with interdomain
>>>>> deployability of existing Diffserv PHBs: it's not really what they were
>>>>> designed for. I'd be happy to be shown counterexamples of n>2-domain
>>>>> deployments at scale involving networks not party to a contract involving
>>>>> DSCP-implemented SLAs, but it really does seem to be that all existing
>>>>> Diffserv PHBs have shown themselves to be irrelevant for the case we are
>>>>> addressing here -- applications on the content side signaling loss/latency
>>>>> tradeoffs to access networks across the open Internet.
>>>>> 
>>>>> The reason to ask for new codepoints is to make it *possible* to continue
>>>>> blocking all existing PHBs while not bleaching PHBs that are not tied in
>>>>> any network (whether by definition or by local configuration) to a request
>>>>> for "better" treatment. A firewall rule could be configured to pass La and
>>>>> Lo (along with other potential future explicit-tradeoff codepoints) while
>>>>> still bleaching other PHBs to DF.
>>>>> 
>>>>> We could potentially do a better job of clarifying this argument in a
>>>>> future draft revision.
>>>>> 
>>>>>> Here are some combinations of existing PHBs that have the potential to
>>>>>> deliver something like the desired behavior:
>>>>>> 
>>>>>> - DF (Default) & EF
>>>>>> - DF (Default) & AFx1 (have to pick an x value)
>>>>>> - AFx1 & EF (have to pick an x value)
>>>>>> - AFx1 & AFy1 (have to pick different x & y values)
>>>>>> 
>>>>>> In all cases, some specific queue configuration is involved to obtain
>>>>>> the desired results, particularly for the queues that correspond to AFx1
>>>>>> & AFy1.  I've included EF because its queue behavior matches latency
>>>>>> preference well - a queue for EF is supposed to deliver low latency in
>>>>>> part by dropping traffic that it can't forward promptly.
>>>>> 
>>>>> Either of these against DF are "request for better treatment": we need
>>>>> some way to distinguish Lo from DF treatment. Though they'd basically be
>>>>> implemented the same way *today*, one can envision future networks
>> where
>>>>> ubiquitous multipath connectivity using different radio technologies means
>>>>> that Lo really *is* a request to go over the lower-loss path.
>>>>> 
>>>>> So we can disregard La = AFx1 / Lo = DF as well as La = EF / Lo = DF.
>>>>> 
>>>>>> OTOH, EF's admission control requirement feels like a poor fit for
>>>>>> what's wanted here.
>>>>> 
>>>>> Yep, so I think we can disregard La = EF / Lo = AFx1
>>>>> 
>>>>> AFx1/AFy1 is intriguing, though rereading 2597 it appears that the
>>>>> "assured" in assured forwarding doesn't quite fit (2597 section 2 para 3):
>>>>> 
>>>>>   A DS node MUST allocate a configurable, minimum amount of forwarding
>>>>>   resources (buffer space and bandwidth) to each implemented AF class.
>>>>>   Each class SHOULD be serviced in a manner to achieve the configured
>>>>>   service rate (bandwidth) over both small and large time scales.
>>>>> 
>>>>> For now, a DS node allocates buffer to Lo and La (where the La minimum
>>>>> might be as small as a single packet), and will practically have to
>>>>> allocate a bandwidth floor for each. But, as above, the actual
>>>>> implementation in the future might rather involve completely different
>>>>> forwarding paths. While these would meet the letter of this paragraph, as
>>>>> there would be an implicit bandwidth floor on each next hop, conceptually
>>>>> the bandwidth requirement is orthogonal to the Lo/La tradeoff, and as such
>>>>> I don't think really fits what I read as the "spirit" of AF.
>>>>> 
>>>>> In addition, this use might collide with some providers' internal use for
>>>>> these codepoints. Of course, this is a potential problem with new
>>>>> codepoints in Pool 3, as well, since these were given over for potential
>>>>> local use in the IANA registry. And it doesn't solve the problem with
>>>>> declaring codepoints potentially unbleachable at all.
>>>>> 
>>>>> Thanks, cheers,
>>>>> 
>>>>> Brian
>>>>> 
>>>>>> I'm not trying to say that this is a solved problem, but I would like to
>>>>>> see more attention paid to possible reuse and/or adaptation of what's
>>>>>> been done before.
>>>>> 
>>>>>> Thanks, --David ++Sent from Android smartphone ...
>>>>>> -------- Original message --------
>>>>>> From: Gorry Fairhurst <[e-mail]>
>>>>>> Date: 3/17/2016 11:02 AM (GMT-05:00)
>>>>>> To: Brian Trammell <[e-mail]>, [e-mail]
>>>>>> Cc: [e-mail]
>>>>>> Subject: Re: presentation slot for draft-you-tsvwg-latency-loss-tradeoff
>>>>>> 
>>>>>> On 17/03/2016 14:49, Brian Trammell wrote:
>>>>>>> Greetings,
>>>>>>> 
>>>>>>> I'd like to request a slot (if one hasn't already been requested) to
>>>>>> quickly present draft-you-tsvwg-latency-loss-tradeoff at the most
>>>>>> appropriate tsvwg session in Buenos Aires.
>>>>>>> 
>>>>>>> Thanks, cheers,
>>>>>>> 
>>>>>>> Brian (for the authors of the loss-latency "one bit" draft)
>>>>>>> 
>>>>>> I'll note the request. I did glance through the draft, and I'm not sure
>>>>>> quite how this fits in to the DS architecture, but I'd need to look
>>>>>> further and consult more to gte a better picture.
>>>>>> 
>>>>>> I need to speak to my co-chair about planning the Agenda, and we'll
>>>>>> discuss - and get back next week.
>>>>>> 
>>>>>> Gorry
>>>>> 
>>>>> 
>>>> 
>>> 
>> Thanks. For me, this helps me get some context. I'll let you continue
>> with David on the actual questions for the moment.
>> 
>> Gorry