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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 22 March 2016 17:28 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: accord@ietfa.amsl.com
Delivered-To: accord@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A9212D16A for <accord@ietfa.amsl.com>; Tue, 22 Mar 2016 10:28:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfVbq281b02v for <accord@ietfa.amsl.com>; Tue, 22 Mar 2016 10:28:23 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 98B1D12D13C for <accord@ietf.org>; Tue, 22 Mar 2016 10:28:23 -0700 (PDT)
Received: from dhcp-207-151.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:6555:b6c0:4612:dbe8]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 65F571B001AB; Tue, 22 Mar 2016 17:40:33 +0000 (GMT)
References: <8AE6BE00-5AC5-4D20-8430-4B7E8E54AEF9@trammell.ch> <56EAC702.9040606@erg.abdn.ac.uk> <ch4u0m0sd69ejdrufypi9g1c.1458528606339@email.android.com> <69C4510B-EB22-4D52-8071-F2902F99D2C1@trammell.ch> <5bc24567872d194ec060397fb72cf193.squirrel@erg.abdn.ac.uk> <56F15B57.4020602@tik.ee.ethz.ch>
To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, Brian Trammell <ietf@trammell.ch>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683.
Message-ID: <56F180B6.70108@erg.abdn.ac.uk>
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: <56F15B57.4020602@tik.ee.ethz.ch>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/accord/0Ij7vzVLGvNJjjrVBnOEj11oR8o>
Cc: "Black, David" <david.black@emc.com>, accord@ietf.org, "tsvwg-chairs@tools.ietf.org" <tsvwg-chairs@tools.ietf.org>, "draft-you-tsvwg-latency-loss-tradeoff@tools.ietf.org" <draft-you-tsvwg-latency-loss-tradeoff@tools.ietf.org>
Subject: Re: [Accord] presentation slot for draft-you-tsvwg-latency-loss-tradeoff
X-BeenThere: accord@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: Alternatives to Content Classification for Operator Resource Deployment <accord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/accord>, <mailto:accord-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/accord/>
List-Post: <mailto:accord@ietf.org>
List-Help: <mailto:accord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/accord>, <mailto:accord-request@ietf.org?subject=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.
>
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, gorry@erg.abdn.ac.uk 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 <david.black@emc.com> 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 <gorry@erg.abdn.ac.uk>
>>>> Date: 3/17/2016 11:02 AM (GMT-05:00)
>>>> To: Brian Trammell <ietf@trammell.ch>ch>, tsvwg-chairs@tools.ietf.org
>>>> Cc: draft-you-tsvwg-latency-loss-tradeoff@tools.ietf.org
>>>> 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
>>>
>>>
>