Re: [tsvwg] Interim meeting agenda for TSVWG April Interim Meetings

Spencer Dawkins at IETF <> Thu, 09 April 2020 12:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B0853A0A49 for <>; Thu, 9 Apr 2020 05:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qh6aCykhKmXX for <>; Thu, 9 Apr 2020 05:37:19 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 08D1D3A0A47 for <>; Thu, 9 Apr 2020 05:37:18 -0700 (PDT)
Received: by with SMTP id x23so7781603lfq.1 for <>; Thu, 09 Apr 2020 05:37:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lRvz1pOl5+wkb9MzD2Aqv6RXohcZYO5VSwhijzd2EGE=; b=rAwd6bj2/wZU2UpeFYczim4IKxXzgy9KtHwKO7rE17RPc0seAm4MKsJZ0sDDNhBhDG 6GgMJHPWXux1HvJhFYq2o+TAWMIat/b2JEE8aQ2C7P4UVZt5W5SCCtt96v+G1QeP3z0t UQnQcFbTMtwYyh8D6zGIw1cbAU4J25z/jJTlHhiKLq4PFIjDcFoj7uH5mhF1eQ8yHZtI 2qKEaknA7sdIT9q+O7JdAsAwTuTwSApcKNGc7pHrLeF4wj/Xwx9ItEmri85w7YN7nNni 5zFWOLTKqLWNRhhQuTMkHaKcvokrSd7AGpuVggoLkLDhktzkVp0oBZ48ZT7pBwwjHlzi e3zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lRvz1pOl5+wkb9MzD2Aqv6RXohcZYO5VSwhijzd2EGE=; b=cJU5mwsvng6zhJ2CkFucFtYRkM9y5A9lpT549idCYO/8SZjqgk46nqnPehie4uBapK eMWPo9dWxQmRqCx7wHkFsECpK1ChKcYB5egZli+PiEDE41foew5mZ73nva8dV6j2K/Ym 7ul9AiCsuj2kT27pZEWnKPI8SuiUQeKMFze9U29CgK37M5BC5kt7T9Fztg6BUw5NoOHD nByCUfvgVSCKGWlkpu/qQu9eDbwDgOWbztSQ0V2EgjRd020Etw6UQKFPTXtqFMn5IhTB BfqVGl6Xq0/DZnEW7PJSiGwLzPL7VrlJJq0Q4jSIrxdtxeuC7cI0mea2b0QVXn6Qw4Iy i3uw==
X-Gm-Message-State: AGi0PuYLjr/8EBUVGE1BomqxHFT/Kj/ti6GuMesQiXEQxB7FvGjuI9Ya 4KDgdl4hZRqsuychQYBqzbM9Lp7sy0OFPZen2YY=
X-Google-Smtp-Source: APiQypKeWW+Hk5YjomePrvY+gZaHCd/WdwgeG8EfAlCMAVAObX+dmH4lrRKqLpYIbBAkYK5t/ANTZCjOpKiQ0B8UI4U=
X-Received: by 2002:ac2:47f0:: with SMTP id b16mr7814460lfp.81.1586435837045; Thu, 09 Apr 2020 05:37:17 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <FRAPR01MB0130D61B392472FF117C6AFC9CC10@FRAPR01MB0130.DEUPRD01.PROD.OUTLOOK.DE>
In-Reply-To: <FRAPR01MB0130D61B392472FF117C6AFC9CC10@FRAPR01MB0130.DEUPRD01.PROD.OUTLOOK.DE>
From: Spencer Dawkins at IETF <>
Date: Thu, 9 Apr 2020 07:36:50 -0500
Message-ID: <>
Cc: tsvwg <>
Content-Type: multipart/alternative; boundary="00000000000086af2005a2dae07d"
Archived-At: <>
Subject: Re: [tsvwg] Interim meeting agenda for TSVWG April Interim Meetings
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Apr 2020 12:37:21 -0000

Hi, Ruediger,

On Thu, Apr 9, 2020 at 2:18 AM <> wrote:

> Hi Spencer,
> I tried to get in contact with 3GPP when LTE and the QCI were introduced.
Thanks for sharing your experience with this - it's WAY deeper than mine!

>    - QCIs are no markings. They are assigned to their connections  from
>    policy node to terminal.
> (I questioned "markings" when I wrote it - thanks for clarifying what I
was trying to say)

>    -
>    - There’s been a 9 standard QCI set which was mapped in no easy to
>    aggregate way to their DiffServ scheme (GSMA IR.34). I proposed changes.
>    - The standard QCIs are not binding. There’s also no binding subset or
>    minimum subset to implement.
>    - The mapping of standard QCIs to applications is not binding.
>    - There are many more private QCIs, which saw deployment at that time.
>    - LTE and likely 5G schedulers are proprietary.
>  I stopped working on that.
>  The best idea that I’ve heard was to introduce a DiffServ scheduler at
> the LTE(5G) sender and run the wireless section without these QCIs on a
> best effort base for all mobile terminals (the have a terminus for that
> mode of operating the wireless section). That would require a rather strong
> push from the mobile operators.
I know that you and David Black co-edited, which was aimed at DiffServ for
operator interconnection, Do you think something like RFC 8100 would be

(and I agree with your point about mobile operators needing to encounter
enough pain to be receptive to that kind of change)

>  I didn’t follow their work on 5G QoS.
Completely understandable :-)

And thanks again for this note.