Minutes IETF106: tsvwg
minutes-106-tsvwg-00

Agenda for TSVWG at IETF 106 Singapore 
WG Chairs: Gorry Fairhurst, David Black, Wes Eddy (remote)

MONDAY, 18th November, 2019, 13:30-15:30  Afternoon Session I, Sophia

1. Agenda

2. Chairs Update: 
          
    RFCs completed:
       RFC8622  Document Shepherd: David
       RFC8682  Document Shepherd: Wes
       RFC8681  Document Shepherd: Wes
       RFC8680  Document Shepherd: Wes
    In RFC-Ed Author-48 state, prior to publication:
 draft-ietf-tsvwg-fecframe-ext  Document Shepherd: Wes
draft-ietf-tsvwg-rlc-fec-scheme Document Shepherd: Wes
draft-ietf-tsvwg-tinymt32       Document Shepherd: Wes
   In RFC-Ed
     draft-ietf-tsvwg-rtcweb-qos Document Shepherd: David
   Drafts beyond WGLC:
       draft-ietf-tsvwg-ecn-encap-guidelines (WGLC) Document Shepherd: David
       draft-ietf-tsvwg-rfc6040update-shim (WGLC)   Document Shepherd: David
       draft-ietf-tsvwg-tunnel-congestion-feedback  Document Shepherd: David
       draft-ietf-tsvwg-transport-encrypt (WGLC)    Document Shepherd: David
       
    Chairs: Milestone updates
          
    WGLC discussion:
       Transport Header Encryption
       draft-ietf-tsvwg-transport-encrypt (WGLC) Document Shepherd: David

David Black: We expect a 2nd WGLC on this draft for the next IETF meeting.
Gorry Fairhust (as editor): We believe we have material to make a new revision 
shortly after, this will go ahead.
Colin Perkins (as author): We were always aiming for a neutral point of view, 
but we clearly missed.
David Black: Yes, I agree that was the intent. 
The next version will be considerably better in this regard.
Tommy Pauly: What do you mean by neutral here? We don't want to set it up as 
an opposition, about should be encrypt header or not. This about where we draw
the boundaries about what we encrypt. There is definitely a pro to encryption, 
we just need to understand the conquences.
David: This describes the consequences, mostly from an in-network point of view. 
It is not supposed to be advocating one way or the other, providing design
 considerations.
Tommy: We should not shy away from saying that there are positive reasons to encrypt,
as we also point out the considerations.
Gorry: Was that an offer to have a look at the text?
Tommy: If we have early versions, I am happy to review it.
Colin: There are sometimes reasons to do other things, and this also needs to be said.
Tommy: I think we agree. Please make sure we have the right tone so people 
outside of this community do not misunderstand this.
Brian Trammell: This document needs more wordsmithing than other documents 
out of TSVWG because there are lots of people picking things apart. 
I also offer to go through the language to find opportunities for misinterpretation. 
I can make that happen next week.

    Chairs: Announcements and Heads-Up.
    These documents that will not be discussed this meeting here:
       draft-ferrieuxhamchaoui-tsvwg-lossbits
       draft-zhuang-tsvwg-open-cc-architecture
       draft-zhuang-tsvwg-ai-ecn-for-dcn
       draft-olteanu-intarea-socks-6
       draft-bonica-intarea-lossless-pmtud
          
       3GPP SA2 contribution on L4S
       https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_136_Reno/Docs/S2-1911250.zip
       3GPP RAN2 contribution
       https://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_107bis/Docs/R2-1913888.zip

3. Feedback on Code Development and Hackathon against working group IDs
          
    3.1 Bob Briscoe: TCP Prague status of implementation and evaluation (8 mins)

Bob presented coding updates since July. Work had been focussed on the missing
code. Accurate ECN is planned to be upstreamed to Linux stack. 
There is now research code on fractional windows.
The was still work on-going to complete the list of topics.
An open slide meeting is organised before the next session.
    
  3.1.1 SCE hackathon update (Jonathan Morton) - no slides

There had been work on interoperability SCE with AccECN. We were able to achieve   
something useful there.
Investigation on bursty link variation on a short timescale - can effect high  
fidelity congestion control, dur to low threshold.
There had been success with a new marking scheme for SCE feedback based on CoDel -    
with a new version of CoDel with two instances of marking, one for CE or one SCE - 
This has considerably better throughput in a bursty environment.
More work is to be done on tuning the parameters.

    3.2 Julius Flohr (Remote): DPLPMTUD for SCTP: implementation and evaluation 
    (This happened after 4.3)

Julius has implemented DPLPMTUD (rev-09) in SCTP and plans to upstream to FreeBSD 
when complete. The focus of work was on IPv4/IPv6 support.

4. SCTP Drafts
          
    4.1 Michael Tuexen (Proxy: G Fairhurst): Bis update to SCTP Spec. 
          draft-ietf-tsvwg-rfc4960-bis

The plan is to review RFC-2119 language and new text to be added.
          
    4.2 Michael Tuexen (Proxy: G Fairhurst): NAT for SCTP (Preparing for WGLC) 
          draft-ietf-tsvwg-natsupp

The text is thought ready for WGLC, but there is one topic to discuss in the next
presentation.

    4.3 M. Boucadair: NAT for SCTP - Proposed Yang Model
        draft-ietf-tsvwg-natsupp

David Black: I understand some of this. The magic word is "augment".
Jake Holland: I have done a little bit with YANG, but I am less familiar with SCTP. 
What are the SCTP VTags used for?
Gorry: It is tied with the NAT state. It will be useful to talk to Michael 
who proposed this. We can close this without doing this or we could do this...
Jake: I have no objection if there is some understanding what those things mean. 
Brian: I think the question is: Is the description internal verification tag 
and external verification enough for someone messing with SCTP on a NAT box? 
And I think so. I think this is fine. Yes, put it in.
Bernard Aboba: Is there an assumption that these drafts will make SCTP work with NAT?
Gorry: There are working SCTP NATs out there. Maybe not in people's home.
Brian: And we would like to configure them with YANG.
David: Sounds like this is moving forward. SCTP people to check the SCTP part 
works, then a trip to the YANG doctor.

Gorry (Chair): Is the SCTP-NAT draft ready (ignoring whether we include the 
Yang model)...  Does anyone think there is additional work?
David: No hands were raised in the room.
David: The Chairs are going to move this forward and ask the authors to add the 
Yang model before WGLC and then get review to move forward to a WGLC.

    4.4 Nagesh Shammer (Remote)
          draft-nagesh-sctp-auth-4895bis-00
          (This happened after 6.1)

Gorry (as Chair): Some of these additions could be filed as errata. 
The normal procedure is to file an errata for smaller issues and see 
if there's consensus. Please file errata and then see what else is on the list.
David: File what can be filed, then work with the other folks in the 
SCTP community, then figure out in the Vancouver timeframe whether more work is needed.

5. Transport Working Group Drafts: Protocols
          
    5.1  Gorry Fairhurst: Datagram PLPMTUD (Preparing for WGLC) 
         draft-ietf-tsvwg-datagram-plpmtud
          (This happened after 4.3)

David Black: What is the timeline for QUIC?
Martin Duke: [About the QUIC schedule] We hope to do WGLC soon-ish,
so maybe Vancouver? Maybe even earlie? There will be a lot of comments 
and require some rework. There is going to be more than one WGLC, 
but the first one will happen in the next quarter.
David Black: UDP options have been separated so we can publish it without 
having to wait, this gets referenced from SCTP draft.
Gorry: I expect the stuff for QUIC is the right text for QUIC. 
The details are in QUIC itself, so I hope there are no real dependencies. 
But we will align these two.
Martin: I have trouble believing that anything changing in QUIC at this point will 
have any impact on PLPMTUD.
David: I expect WGLC in the near future. Is anyone else willing to review? 
Martin and Ian Swett.
Gorry: Please read this. We accept comments on any aspects, including readability.

6. New Work
          
    6.1 Greg White: Identifying and Handling Non-Queue Building Flows 
        draft-ietf-tsvwg-nqb
        
The idea is to mark with a verifiable behavior.

(slide 5: queue-building traffic)
David Black (as individual): There is an open SHOULD vs MUST. 
It is possible that the word  "node" in that last requirement 
might be able to be removed. It is possible that you could
do what DOCSIS has done to evict queue-building traffic to
a separate quue. 
You might also be able to bring some kind of admission control. 
If you do not have a protection on the PHB. This looks like EF.
Greg: Agree this could be more flexible. Supporting the PHB has visibilty 
into what traffic is causing queueing.
Bob Briscoe: About "node", to be verifiable, this needs to be on 
the node that has the queue. It is different to a DiffServ domain 
where you can have edge protection or policing, there you get a contract, 
you don't get a contract here.
David: I still think there's some flexibility possible here, and we
can talk more.

(slide 7; WiFi)
Jonathan Morton: I think there is some WiFi equipment that already meets 
the NQB requirement, but without an actual code point. Because they 
implement FQ Codel on a per-station basis.
Andrew McGregor: The WiFi MACs varies in many other parameters 
associated with the queue. I think that NQB and WiFi queueing are 
kind of orthogonal. You likely want to have more one DSCP because 
you also may need to distinguish between queue-building and not 
in the VI queue. I am just saying there's more  parameters here. 
Aggregate building characteristics are different. 
Greg: Is that configuration?
Andrew McGregor:  You can't just do that, because it's not reflected in 
all hardware.

(slide 8; DSCP)
Is it possible to influence the QoS map in home networks?

Bob: We ought to agree on the requirements for the code points first.
Chairs: Agree, Please discuss on the list.

    6.2 Markus Amend: DCCP Extensions for Multipath Operation
          draft-amend-tsvwg-dccp-udp-header-conversion
          draft-amend-tsvwg-multipath-dccp
          draft-amend-tsvwg-multipath-framework-mpdccp
(Moved to Thursday)

    6.3 Gorry Fairhurst: Guidelines for Internet Congestion Control at Endpoints 
          draft-fairhurst-tsvwg-cc

David: I volunteer, once I survive the transport header encryption draft.
Jana Iyengar: I did read the draft. I have some specific comments, which
I will talk through off-line. I think the work should be done.
Looking into the text that has been written,  I find it difficult to 
find a real recommendation that we can apply. 
I am looking for something more concrete than RFC 2914.
Something between RFC 2914 and specifying exact behavior. 
It's very relevant, important, useful to have that. 
Your box is talking about specific transports, but any new protocol should use this.
The current text in the draft is focussed on our past experience with TCP.
Gorry: The existing RFCs were written with TCP in mind, because that is 
the only starting point we can have. We can try to get there.
Markku Kojo: Have read this, it looks useful, I care.
Very careful considerations need to be made to encompass this, and in
 particular we need to think what else to include?. And we need
to separate thinking that is still experimental.
Gorry: Interesting.
Praveen: I care and I think it is really important. Should apply to all transports.
Bob: Yes, it is important. Having done the first round, it might be worth 
taking out stuff that isn't really saying anything new. 
To more focus in things that have changed. For instance, the burst stuff, that 
is newer than RFC2914. 
New ideas are coming out with fairness, as mentioned in ICCRG. 
Try not to repeat stuff from the past, but things that may be more controversial.
Gorry: OK. I think we could try adding a short section that clearly calls out what
is mew and see if that address that point?
Yoshifumi Nishida: In TCPM we have RTO considerations. There are several overlaps. 
If TSVWG will be the venue of this draft, this WG should decide how to treat this.
Gorry: RTO considerations seems now complete, we are restating some of that here. 
The overlap is not intended to be in contention. 
We should reconcile this between the Working Groups, and we have to ensure that if two
documents are published they compliment each other.

Gorry: Can we do this in this WG?
David: I think we can do this work here, but an adoption call is a little 
premature. There are people interested in working on this draft, and
we can likely have an adoption call in Vancouver.
Gorry: I am looking for people to talk to about this, I want to work with others
to make a better document available for the next IETF meeting.
Jana: I will comment on the next revision.
Bob: To be clear about what I said before: Previous advice is still important,
we just do not need to say it again. I was thinking about Sally Floyd, and
the fact she kept on saying this. This is probably the reason so many people 
now understand it. 
Jana: I think Bob just volunteered?
Jana: I am trying to find some time this week.
Gorry: I am doing this as an individual, but I only will continue if other 
people talk to me to define the box together.

The first session closed.

THURSDAY, 21ST November, 2019,  10:00-12:00  Morning Session I - Canning

<< to be uploaded>>