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

Brian Trammell <ietf@trammell.ch> Wed, 30 March 2016 13:42 UTC

Return-Path: <ietf@trammell.ch>
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 711D612D186 for <accord@ietfa.amsl.com>; Wed, 30 Mar 2016 06:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level:
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 eJFCgbt8N867 for <accord@ietfa.amsl.com>; Wed, 30 Mar 2016 06:42:29 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id AF37612D717 for <accord@ietf.org>; Wed, 30 Mar 2016 06:36:59 -0700 (PDT)
Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id 6F24E1A02A3; Wed, 30 Mar 2016 15:36:28 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_B381FE69-B81C-414B-A620-0C7C92CC63D0"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.6b2
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362E92081D@MX104CL02.corp.emc.com>
Date: Wed, 30 Mar 2016 15:36:55 +0200
Message-Id: <79F6B53E-DA60-454F-8585-6747105768B3@trammell.ch>
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> <63DA58B9-4730-4D49-A009-3997996F9012@trammell.ch> <56F181C1.2080600@erg.abdn.ac.uk> <CE03DB3D7B45C245BCA0D243277949362E92081D@MX104CL02.corp.emc.com>
To: "Black, David" <david.black@emc.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/accord/4vxJugVrsoxFxJeGm99lVMEthEw>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "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>, "accord@ietf.org" <accord@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
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: Wed, 30 Mar 2016 13:42:37 -0000

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 <david.black@emc.com> 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:gorry@erg.abdn.ac.uk]
>> Sent: Tuesday, March 22, 2016 1:33 PM
>> To: Brian Trammell
>> Cc: Black, David; tsvwg-chairs@tools.ietf.org; draft-you-tsvwg-latency-loss-
>> tradeoff@tools.ietf.org; accord@ietf.org
>> 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, 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.
>>> 
>>> 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 <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
>>>>> 
>>>>> 
>>>> 
>>> 
>> Thanks. For me, this helps me get some context. I'll let you continue
>> with David on the actual questions for the moment.
>> 
>> Gorry