Subject: Re: [tsvwg] Interim meeting requests

From: "Rodney W. Grimes" <[email-masked]>
Date: Sun, 5 Apr 2020 21:40:55 -0700 (PDT)

> The IESG is running a conflict avoidance protocol that involves assigning each time slot in the cancelled Vancouver meetings to a day (helps avoid ADs needing to be in two meetings simultaneously).
> 
> TSVWG's suggested days are Wed, April 8 and Mon, April 27, and the chairs have chosen 1400-1630 UTC as the time slot (NB: much of the world is on summer time in April, e.g., this will be 0700 local in California, not 0600).  The rough rationale for that time slot is to spread the seriously inconvenient hours of night (0100-0700) across the Pacific Ocean.
> 
> The chairs plan to take up ECT(1), L4S, SCE and related topics on April 27, devoting April 8 to everything else that needs attention now and to discussion of the plan for April 27.  Stay tuned for meeting agendas.
> 
> Thanks, --David (TSVWG co-chair)

I have not seen any announcement on the list about an Agenda
for either April 8th, or 27th, but I did find in the datatracker
that a set of chair slides which contain agenda info for
both is posted at:
https://datatracker.ietf.org/doc/slides-interim-2020-tsvwg-02-sessa-1-chairs-slides/

Regards,
Rod

> ----------------------------------------------------------------
> David L. Black, Sr. Distinguished Engineer, Dell EMC
> Dell Technologies, Infrastructure Systems Group
> 176 South St., Hopkinton, MA  01748
> +1 (774) 350-9323<tel:+17743509323>           Mobile: +1 (978) 394-7754<tel:+19783947754>
> [email-masked]<mailto:[email-masked]>
> ----------------------------------------------------------------

-- 
Rod Grimes                                                 [email-masked]

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 6 Apr 2020 08:11:32 +0100

TSVWG,

Here is the (shortened) agenda for the on-line interim meetings, based 
on the Agenda submitted for the Vancouver IETF. If you are scheduled to 
present in Interim 1 (WG document status), please send slides for us to 
upload to the meeting materials page. We will shortly distribute 
information for Interim 2.

Best wishes,

Gorry

(TSVWG Co-Chairs)

---

Wednesday Apr-08-2020 1000
0700-0930 UTC-7 (San Francisco) = 1000-1230 UTC-4 (Boston) = 1500-1730 
UTC+1 (London) = 1600-1830 UTC+2 (Berlin) = 2200-0030[+1] UTC+8 (Beijing 
- not on summer time, other 4 are)

TSWG Interim #1
WG Chairs: Gorry Fairhurst (remote), David Black  (remote), Wes Eddy 
(remote)

1. Agenda (5 mins)

2. Chairs Update: (10 mins)

         Note Well

         RFC's completed/in Queue:
         RFC 8680 (was draft-ietf-tsvwg-fecframe-ext) (Jan 2020)
         RFC 8681 (was draft-ietf-tsvwg-rlc-fec-scheme) (Jan 2020)
         RFC 8682 (was draft-ietf-tsvwg-tinymt32) (Jan 2020)
         draft-ietf-tsvwg-rtcweb-qos (RFC Ed Queue : MISREF for 1293 days)

         Drafts beyond WGLC:
         draft-ietf-tsvwg-datagram-plpmtud (IETF-LC) Document Shepherd: Wes
         IESG

         draft-ietf-tsvwg-transport-encrypt (WGLC) Document Shepherd: David
         2nd WGLC closed 16 March 2020

         draft-ietf-tsvwg-ecn-encap-guidelines (WGLC) Document Shepherd: 
David
         With WG Chairs

         draft-ietf-tsvwg-rfc6040update-shim (WGLC) Document Shepherd: David
         With WG Chairs

         Chairs: Milestone updates

         Chairs: Announcements and Heads-Up
         draft-kuehlewind-system-ports (Non-WG ID)
         draft-ietf-tcpm-rto-consider (Joint TCPM WGLC)

4. L4S and ECN
         Chairs: Plan for 2nd Interm

4. SCTP Drafts
         4.1   Michael Tuexen: bis update two SCTP Spec (10 mins)
         draft-ietf-tsvwg-rfc4960-bis
         4.2   Michael Tuexen: NAT for SCTP (Preparing for WGLC) (10 mins)
         draft-ietf-tsvwg-natsupp - Post yang doctor

5. Transport Working Group Drafts: Protocols
         5.1   Joe Touch (proxy/remote): UDP Options (5 mins) - Plans to 
revise
         draft-ietf-tsvwg-udp-options
         5.2   Greg White: Identifying and Handling NQB Flows (10 mins) 
- DSCP?
         draft-ietf-tsvwg-nqb

6. Individual Drafts
         6.1   Martin Duke: Network Address Translation Support for QUIC 
(10 mins)
         duke-quic-natsupp-00.txt
         6.2   Jerome Henry: QCI and Diffserv API (10 mins)
         draft-henry-tsvwg-diffserv-to-qci

Monday Apr-27-2020 1000
0700-0930 UTC-7 (San Francisco) = 1000-1230 UTC-4 (Boston) = 1500-1730 
UTC+1 (London) = 1600-1830 UTC+2 (Berlin) = 2200-0030[+1] UTC+8 (Beijing 
- not on summer time, other 4 are)

TSWG Interim #2
WG Chairs: Gorry Fairhurst (remote), David Black  (remote), Wes Eddy 
(remote)

1. Agenda (5 mins)

2. Chairs Update: (5 mins)

         Note Well

3. L4S and ECN
         ECT(1) usage
         ECT(1): Agreeing on the Decision to be Made
         What is the goal of this WG in 2020?
         Friendly Coexistence with Competing Traffic
         Experimental Deployment
         RFC-Series and ECT(1)  ggg

4. Chairs Summary of Position

---

Remote Interim Instructions

Register for the IETF meeting (free)
https://www6.ietf.org/registration/ietf107/remoteattendance.py

Join the interim meeting via webex
You MUST add your name to Etherpad (Blue Sheets)
Use Jabber for remote chat
https://www.ietf.org/how/meetings/jabber/

Information on how to do this:
https://www.ietf.org/how/meetings/107/session-participant-guide/

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 6 Apr 2020 10:35:31 -0700

None of the links in the trailing message work for me. I am directed to the
IETF 107 meeting site, where registration is closed and only the MArch
meetings are listed. What am I missing?

Mike Heard

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 6 Apr 2020 17:49:51 +0000

Hi Mike, hi all,

actually you don’t need to register for this interim meeting. That’s was only for the meetings scheduled during the virtual IETF-107 week to get some statistical information.

Mirja

From: tsvwg <[email-masked]> on behalf of "C. M. Heard" <[email-masked]>
Date: Monday, 6. April 2020 at 19:36
To: Gorry Fairhurst <[email-masked]>
Cc: TSVWG <[email-masked]>
Subject: Re: [tsvwg] Interim meeting agenda for TSVWG April Interim Meetings

None of the links in the trailing message work for me. I am directed to the IETF 107 meeting site, where registration is closed and only the MArch meetings are listed. What am I missing?

Mike Heard

On Mon, Apr 6, 2020 at 12:12 AM Gorry Fairhurst <[email-masked]<mailto:[email-masked]>> wrote:
TSVWG,

Best wishes,

Gorry

(TSVWG Co-Chairs)

---

TSWG Interim #1

1. Agenda (5 mins)

         Note Well

         Drafts beyond WGLC:

4. L4S and ECN

4. SCTP Drafts

6. Individual Drafts

Monday Apr-27-2020 1000

TSWG Interim #2

1. Agenda (5 mins)

         Note Well

3. L4S and ECN
         ECT(1) usage

---

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 6 Apr 2020 20:53:59 +0100

Sorry, I don't think you need to (or can) register - It's been 
classified as an interim...

The other info is still useful.

Gorry

On 06/04/2020 18:35, C. M. Heard wrote:
> None of the links in the trailing message work for me. I am directed 
> to the IETF 107 meeting site, where registration is closed and only 
> the MArch meetings are listed. What am I missing?
>
> Mike Heard
>

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 6 Apr 2020 20:00:51 -0700

In case this is as unobvious to some other folks as it was to me, the list
of upcoming interim meeting is here:

https://datatracker.ietf.org/meeting/upcoming

At this time we still do not seem to have a Webex meeting set up for tsvwg.

On Mon, Apr 6, 2020 at 12:54 PM Gorry Fairhurst <[email-masked]>
wrote:

> Sorry, I don't think you need to (or can) register - It's been classified
> as an interim...
>
> None of the links in the trailing message work for me. I am directed to
> the IETF 107 meeting site, where registration is closed and only the MArch

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 8 Apr 2020 11:17:28 -0500

I didn't say this at the mike, so it won't be in the minutes, but ...

> - not on summer time, other 4 are)

(deleted down to)

>          draft-henry-tsvwg-diffserv-to-qci

The other reason I hope TSVWG pushes a bit more in this space is that the
final answer may be either "you guys should really be using diffserv" or
"you guys are working on new 5G markers and you can't map the ones you
already have onto diffserv now, so good luck" ... and I could live with
either answer, if it was written down.

No snark intended.

Best,

Spencer

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Wed, 8 Apr 2020 16:36:36 -0700 (PDT)

> either answer, if it was written down.

A strong +1, I do understand that the carriers have a far more
robust set of traffic types to deal with, but I would think
some order of alignment in the space should be attempted.

Infact given that the carriers are also carriers of internet
traffic I would of thought that some mapping was already in
place.

Regards,

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 8 Apr 2020 19:54:05 -0500

Hi, Rodney,

> traffic I would of thought that some mapping was already in

^^^^ THIS. I hadn't ever asked myself that question, but that might be a
good question for us to keep in mind.

What DO they do now?

Best,

Spencer

---

From: <[email-masked]>
Date: Thu, 9 Apr 2020 07:18:36 +0000

Hi Spencer,

I tried to get in contact with 3GPP when LTE and the QCI were introduced.

  *   QCIs are no markings. They are assigned to their connections  from policy node to terminal.
  *   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 didn’t follow their work on 5G QoS.

Regards.

Ruediger

Von: tsvwg <[email-masked]> Im Auftrag von Spencer Dawkins at IETF

Gesendet: Donnerstag, 9. April 2020 02:54

An: Rodney W. Grimes <[email-masked]>

Cc: Gorry Fairhurst <[email-masked]>; [email-masked]

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

Hi, Rodney,

> On Mon, Apr 6, 2020 at 2:12 AM Gorry Fairhurst <mailto:[email-masked]> wrote:

place.

^^^^ THIS. I hadn't ever asked myself that question, but that might be a good question for us to keep in mind.

What DO they do now?

Best,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 9 Apr 2020 07:36:50 -0500

Hi, Ruediger,

> 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.
>
>  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
https://datatracker.ietf.org/doc/rfc8100/, which was aimed at DiffServ for
operator interconnection, Do you think something like RFC 8100 would be
helpful?

(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.

Best,

Spencer

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Mon, 13 Apr 2020 18:01:01 +0000

Thank you Ruediger,

This is very useful.
It seems to me that, since release 8, 3GPP has continuously worked at refining the definitions of traffic types, and at defining new types.  Today, I would tend to say that they have explored traffic types that the DIffserv world has not fully explored yet.
Offering a map to Diffserv may be useful in that regard. A longer term effort might also be to more deeply explore the world of automation and virtual reality, to define more precisely the traffic categories that Diffserv would expect there. This could be a second wave of efforts.

Thanks again for your feedback.

Best

Jerome

From: tsvwg <[email-masked]> on behalf of Spencer Dawkins at IETF <[email-masked]>
Date: Thursday, April 9, 2020 at 8:37 AM
To: "[email-masked]" <[email-masked]>
Cc: tsvwg <[email-masked]>
Subject: Re: [tsvwg] Interim meeting agenda for TSVWG April Interim Meetings

Hi, Ruediger,

On Thu, Apr 9, 2020 at 2:18 AM <[email-masked]<mailto:[email-masked]>> wrote:

Hi Spencer,

  *   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 are many more private QCIs, which saw deployment at that time..

 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 https://datatracker.ietf.org/doc/rfc8100/, which was aimed at DiffServ for operator interconnection, Do you think something like RFC 8100 would be helpful?

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

Best,

Spencer