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

Gorry Fairhurst <> Tue, 22 March 2016 17:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 45A9212D16A for <>; Tue, 22 Mar 2016 10:28:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RfVbq281b02v for <>; Tue, 22 Mar 2016 10:28:23 -0700 (PDT)
Received: from ( [IPv6:2001:630:241:204::f0f0]) by (Postfix) with ESMTP id 98B1D12D13C for <>; Tue, 22 Mar 2016 10:28:23 -0700 (PDT)
Received: from (unknown [IPv6:2001:630:241:207:6555:b6c0:4612:dbe8]) by (Postfix) with ESMTPSA id 65F571B001AB; Tue, 22 Mar 2016 17:40:33 +0000 (GMT)
References: <> <> <> <> <> <>
To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= <>, Brian Trammell <>
From: Gorry Fairhurst <>
Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683.
Message-ID: <>
Date: Tue, 22 Mar 2016 17:28:22 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc: "Black, David" <>,, "" <>, "" <>
Subject: Re: [Accord] presentation slot for draft-you-tsvwg-latency-loss-tradeoff
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Alternatives to Content Classification for Operator Resource Deployment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Mar 2016 17:28:27 -0000

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.

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.


> Thanks!
> Mirja
> On 22.03.2016 10:23, 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 <> wrote:
>>>> I'd think that this draft is also planned for presentation in the
>>>> 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 <>
>>>> Date: 3/17/2016 11:02 AM (GMT-05:00)
>>>> To: Brian Trammell <>ch>,
>>>> Cc:
>>>> 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