* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Tsvwg Status Pages

Transport Area Working Group (Active WG)
Tsv Area: Mirja K├╝hlewind, Spencer Dawkins | 1999-Oct-22 —  
Chairs
 
 
 
 
 
 


IETF-100 tsvwg minutes

Session 2017-11-13 1740-1840: Canning - Audio stream - tsvwg chatroom
Session 2017-11-17 0930-1130: Collyer - Audio stream - tsvwg chatroom

Minutes

minutes-100-tsvwg-03 minutes



          IETF-100 TSVWG Meeting
          
          Monday Afternoon session
          Notetaker: Brian Carpenter (thanks!)
          
          1. Chairs:
          The chairs presented the WG slides, noted completed RFCs, milestones,
          etc.
          
          RFC's completed:
          draft-ietf-tsvwg-sctp-dtls-encaps
          draft-ietf-tsvwg-sctp-dtls-ndata (I-data)
          
          Other WG drafts:
          draft-ietf-tsvwg-ecn-experimentation (post IESG, will be at RFC Editor
          soon)
          draft-ietf-tsvwg-ieee-802-11 (IESG)
          draft-ietf-tsvwg-tunnel-congestion-feedback (work needed)
          draft-ietf-tsvwg-udp-options
          
          2.Individual drafts:
          
          2.1 Note detnet WG discussion of draft-thubert-tsvwg-detnet-transport
          (in detnet WG)
          
          3. ECN encapsulation (Bob Briscoe)
          draft-ietf-tsvwg-rfc6040update-shim
          
          draft-ietf-tsvwg-ecn-encap-guidelines
          Bob reviewed rev -05 of Propagating ECN across IP tunnel Headers Separated
          by a Shim
          
          David: We expect to progress the tunnel and shim encapsulation drafts
          together.
          Bob Briscoe: January would be a suitable milestone for both drafts.
          
          People willing to review these drafts:
          Joel Jaeggli
          Stuart Cheshire
          
          4. LE PHB, round 1 (Roland Bless)
          draft-ietf-tsvwg-le-phb
          
          One serious open issue remains: DSCP selection, since issues had been
          raised on the proposed code point of DSCP 2 voiced in Prague.
          Gorry reviewed the discussion in Prague and asked the WG to consider
          the options and be ready to make a recommendation by the second meeting.
          Brian Carpenter: One of the characteristics of Pool 3 is that it currently
          is permitted for local or experimental use.
          Gorry: Yes, and if such an operator understands how to use Pool 3,
          then they could be expected to know how to remap that at the network
          boundary. It may of course remap this to zero.
          Bob Briscoe: Is marking up to zero OK really OK?
          Gorry: Roland's draft says you should also use a LBE transport to protect
          the Default traffic.
          Andrew McGregor: We have networks that provide a LE code point and
          cases where LE and BE traffic has to share a queue, and the use of a
          LBE transport works fine in that case.
          
          5. Individual ID (Colin Perkins)
          draft-fairhurst-tsvwg-transport-encrypt
          
          The draft had been presented in OPSEC and there was interest from there
          in a document on this topic.
          
          Lars Eggert: QUIC is working on a protocol that has encryption. There
          is a design team to consider whether there is a need for information to
          help operations. What happens if this work concludes something different
          to what QUIC decides to do? QUIC is on a short schedule.
          Colin Perkins: QUIC is on an accelerated plan that is not taking as much
          input as it could. This is a consideration for the IETF.
          David Black: If QUIC is the first example, then attention should be
          focused there.
          Colin Perkins: The draft is about what needs to be done and not what
          needs to be changed.
          Lars Eggert: I am concerned the IETF-QUIC will be blocked if nothing
          happens. That is a concern if the IETF QUIC is not progressed, while we
          wait for an outcome here.
          Spencer (AD): This document is targeting informational. It seem crazy to
          hold other WG work on the basis of an informational draft. What is the
          intended audience for this draft if not QUIC? I think it is brilliant
          and we should have been working on this all along. I want to be sure
          the document is useful.
          Brian Trammell: I edit the QUIC manageability of the document that
          specifically addresses the concerns wrt to QUIC. I really think it
          is useful to have a document that targets the transport issues. This
          approach on looking at the impact of the people in this room may be a
          way to make progress. I think the insights here need to get into the
          other drafts. I assume you have looked at the things that are relevant
          in other documents at the IETF?
          Colin Perkins: We think we have looked at these (we may have missed some -
          if we have let us know.)
          Flemming Andreas: I agree with the message here.
          Roni Even: I support this document, we need to balance security and
          manageability.
          Joel Jaeggli: I am largely sympathetic to end system protection from
          meddling, but also have to protect endpoints in scalable ways from
          devices that just send packets.
          Lars Eggert: The integrity protection part is a part, but also the ability
          to prevent middleboxes ossifying on the stack. It would be good to know
          what operators think are needed.
          Colin Perkins: The trade-off is whether some ossification is good
          or bad. Not changing some parts indicates success - we need to decide
          carefully what we expose and what can change. Some forms of ossification
          are actually good.
          Mark Townsley: The cat-and-mouse game to figure out what is needed is
          a race to the bottom. We should step back and work out what needs to be
          exposed. We need to figure out the right data to expose for the correct
          reasons.
          
          WG Chairs (David): Please continue to read the draft and discuss on the
          list.
          
          -------------------------------------------------------------------------
          
          Friday Morning session
          Notetaker: Stuart Cheshire (thanks!)
          
          6. Agenda Part 2
          
          6.1 Chairs slides
          
          The SCTP ndata ID has now been approved by RFC-Ed.
          
          Revision -08 of ECN Experimentation was announced 2017-11-13.
          The chairs do not expect new issues, but ask the WG to please confirm
          the final text is correct- there have been changes since WGLC. (gorry
          will remind people on the list).
          Please review changes by 23rd Nov 2017
          
          6.2 AQM: draft-finzi-priority-switching-scheduler (Fred Baker)
          This is a proposal is to make elastic traffic more predictable.
          The chairs confirmed this is the appropriate WG to discuss AQM.
          
          Please discuss this ID on the draft to find out if there is interest,
          operational use, and what people think is appropriate to do with this
          draft if it is taken forward.
          
          7. SCTP (Maksim Proshin)
          draft-tuexen-tsvwg-sctp-udp-encaps-cons
          No change since last IETF.
          
          draft-ietf-tsvwg-natsupp
          No change since last IETF.
          
          draft-ietf-tsvwg-rfc4960-errata
          Revision -03 incorporates the remaining known issues.
          
          Chairs: Is there anyone who can look at the Linux implementation to see
          if there is any feedback.
          
          The chairs will ask for reviewers on the list, please tell the
          chairs. Once we a list of reviewers the WG plans to start a WGLC. (Started
          after the meeting.)
          
          8. L4S (Bob Briscoe)
          draft-ietf-tsvwg-ecn-l4s-id
          draft-ietf-tsvwg-l4s-arch
          These drafts have not been significantly changed. There had been progress
          with 3GPP in clarifying the operation of ECN, but a proposal to add ECN
          support to RLC was not taken forward in release 15. There is intention
          to retry for release 16.
          
          draft-ietf-tsvwg-aqm-dualq-coupled
          The document will be updated to include experiment considerations.
          
          David Black (from the floor): I am interested in how a dual-queue
          structure relates to DiffServ, and whether there would be multiple
          instances of the queues matching diffserv aggregates.
          
          Michael Welzl: Is there a simple way to specify the AQMs that can fit
          within the framework?
          Bob: Yes this is the intention of the architecture ID.
          
          An update is planned before IETF-101.
          
          9. LE PHB, round 2 (Roland Bless)
          draft-ietf-tsvwg-le-phb
          Measurements from Aberdeen University showed that the group needed to
          consider other traffic aggregates that may be mapped to DSCP 2. Roland
          provided an update on the draft, and will propose a new DCSP choice.
          
          The WG will consider a process draft to allow DSCP allocations for
          standard PHBs in Pool 3.  The LE PHB draft will have to wait for that in
          order to allocate a Pool 3 DSCP (both DSCP 1 and DSCP 5 are in Pool 3).
          
          Brian Carpenter: I have sympathy with this request. I think routers
          that do what the architecture requires will be OK. I think a standards
          document (PS) update is needed to over-ride the current allocation
          method. I assume this is standards-action?
          Gorry Fairhurst: Yes, It would be standards-action. Do you think we
          should reserve DSCPs 1 and 5 for IETF assignment, or should we grab the
          whole pool?
          Brian Carpenter: I think this should change assignments for the entire
          pool.
          David Black: I think we should try this approach for the entire of Pool
          3.
          
          WG please tell us whether a DSCP of 1 or 5 is most suited. Will add text
          that relates to the draft-ietf-tsvwg-ieee-802-11  (based on running code)
          and possibly updates that RFC-to-be, to be decided.
          
          [Clarification: the text to be added to ietf-tsvwg-ieee-802-11 now is
          to state that a new DSCP is being assigned - that draft will not wait
          for the assignment to be performed.]
          
          10. FECFRAME (Vincent Rocca)
          draft-ietf-tsvwg-fecframe-ext
          draft-ietf-tsvwg-rlc-fec-scheme
          
          David Black (individual): The density parameter is currently specified
          linearly, maybe an exponential encoding may provide more dynamic range?
          Vincent: OK, I understand,
          
          Both documents could be ready for IETF-101 or shortly after. Please
          discuss on the list.
          
          New drafts to be considered by the WG:
          
          11 draft-fairhurst-tsvwg-datagram-plpmtud (Gorry Fairhurst)
          The draft had briefly been presented in INTAREA at IETF-100 and there
          seemed interest there in TSVWG doing work on this topic.
          
          Authors requested working group adoption.
          Mikael Abrahamson: This is a real problem. Do we know how many TCP hosts
          use PLPMTUD? Can someone find this out - it is interesting to know if
          hosts have PLPMTUD enabled by default.
          Maksim Proshim: I support this work, there are issues in this area. What
          do you do with data packets sent with the wrong pmts?
          Gorry Fairhurst: This depends on the transport, so that's not our
          responsibility, but we do say how to handle the probes.
          Maksim Proshin: It's hard to re-fragment for SCTP.
          Gorry Fairhurst: Indeed, speak to the SCTP people - also see the end of
          the draft for other issues.
          Vincent Roca: I support this draft, and have done some work surveying
          PMTU.
          Bob Hinden: I support this work, we should have done this before. Have
          you thought about DNS/DNSsec?
          Gorry Fairhurst: I heard it may help - I do not know DNS, so anyone
          interested in this please talk to me about how to do this.
          Mikael Abrahamson: Is this for the UDP apps developer, OS?
          Gorry Fairhurst: Could be done in UDP options in the stack (keeping the
          same 5-tuple); could be added to an IETF transport; could be done in
          the app.
          M Abrahamson: Applications may wish to be involved.
          Spencer Dawkins (AD): Applications have deployed really conservative
          packet sizes to ensure the paths work. It may be good to talk to the
          apps folks about what happens when this is deployed.
          Chairs (David Black): Please raise hand if you have read the draft (few).
          Please hum if you think TSVWG should adopt this draft (hum for).
          Please hum if you think the TSVWG should not adopt (none).
          Chairs (David Black): We will start an adoption call on the list.
          
          12.draft-han-6man-in-band-signaling-for-transport-qos (Lin Han)
          A proposal for a sub-transport layer for IPv6 that can provide QoS,
          path-aware routing that can take advantage of advanced hardware router
          functions. Targets apps needing high capacity or low latency. The work
          has been discussed in ETSI Next Generation Protocol.
          Gorry Fairhurst: When do you expect the ETSI NGP project to complete?
          Lin Han: This work time may be ready by the end of the year.
          Gorry Fairhurst: Is there more than one work item?
          Lin Han: Yes, this is one of many items.
          Roland Bless: I see issues at various levels. It seems you do not pass
          the resource messages with the data.
          Lin Han: We try to reduce the complexity compared to RSVP. The network
          can release resources if they are not used (e.g., up to 8 seconds). We
          have security mappings and can authorise the users.
          Michael Scharf (relayed from Jabber): Please see RFC 6077 that describes
          many of the issues that need to be considered in such designs.
          Mikael Abrahamson: There is a business model concern here. Do you want
          to work across multiple domains?
          Lin Han: We currently only look at one single domain.
          David Black (as individual): This seems scoped to a single operator
          domain. Is there an incremental deployment method? How will this behave
          if part of the network does not support this?
          Lin Han: This is simpler than ATM. The source knows if it works.
          David Black (as individual): This looks like a single operator "walled
          garden" design.
          Bob Briscoe: I have read the draft, and do not think there is discussion
          of layer 2 elements or tunnels.
          Lin Han: There are other issues with more complexity. This is just a
          pure IP domain.
          
          Chairs (gorry): What are your intentions with respect to this draft?
          Lin Han: We are interested in liaison with the IETF and to learn.
          Chairs (gorry): Are the present ETSI documents available to this working
          group? Please share progress with the list and see if there is interest
          in the various components that have been presented.
          
          Meeting closed.
          
          



Generated from PyHt script /wg/tsvwg/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -