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

[Gorry Fairhurst <[e-mail]>]

On 22/03/2016 14:48, Mirja Kühlewind wrote:
> Hi Gorry, hi David,
>
> accord currently is a non-wg forming BoF and I personally don't see a
> working coming out of it. Currently the questions is rather, what do we
> want to do and where can we do it (and 'where' might be existing working
> groups). However, even if there would be a new accord wg or something
> like this, I would still see that a new DSCP should be allocated only in
> tsvwg because that's were the expertise is.
 >
I concur with the above. One good thing is ACCORD could help motivate 
the use-case?

 >  So my current view is, even
> if we discuss and present this in accord (where the focus is clearly on
> what we want to do, and not the explicit codepodes itself), this doc
> would always stay a tsvwg doc. In this case, for me the questions is, do
> you have time on the agenda for a heads-up presentation that this new
> work might be coming up (and for us to get early feedback similar to
> what you provided already), or not...? Both is okay for us, as this is
> early work.
>
Let's add to the list of drafts requesting time.

> Btw. could we maybe restart this discuss on the tsvwg mailing list...? I
> think it would be very useful for us to have the discussion there and
> get feedback from the broader community.
>
Yes.

However, I'm pretty much confused about whether there is merit in 
specifying these new PHBs.  This could be just because this is draft -00.

Gorry


> Thanks!
> Mirja
>
>
> On 22.03.2016 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. From the current, I still need to
>> understand why the code points would be needed and why new ones would
>> help. 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.
>>
>> 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.
>>
>> Gorry
>>
>>> 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
>>>
>>>
>