* 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 —  

IETF-102 tsvwg minutes

Session 2018-07-19 1550-1750: Centre Ville - Audio stream - tsvwg chatroom
Session 2018-07-19 1810-1910: Centre Ville - Audio stream - tsvwg chatroom


minutes-102-tsvwg-01 minutes

          IETF 102  Montreal July 15 - 20, 2018
          Draft Agenda
          WG Chairs: Gorry Fairhurst, David Black, Wes Eddy (remote)
          Note Takers: Tommy Pauly, Tom Jones
          Session I: Thursday Jul-19-2018 1550
          1. Chairs Update:
            RFCs completed:
            Chairs update on:
               draft-ietf-tsvwg-iana-dscp-registry (RFC-Ed)
               draft-ietf-tsvwg-rfc4960-errata (IESG) - see later
               draft-ietf-tsvwg-fecframe-ext (Post WGLC)
               draft-ietf-tsvwg-rlc-fec-scheme (Post WGLC)
               draft-ietf-tsvwg-le-phb  (WGLC)
            Milestone updates and review of WG Progress:
              Feedback on draft-ietf-tsvwg-tunnel-congestion-feedback (Waiting
              for editors)
              Update on ecn-encap-guidelines and 6040update-shim (Waiting for WGLC)
          Originally wanted ECN encapsulation drafts out for June 2018, but moving
          those to Oct 2018.
          L4S drafts are aiming for September, but chairs think this may be a bit
          optimistic and we want to push those out.
          Tunnel Congestion feedback will likely be adjusted in the Bangkok
          Moving ahead and on schedule for all other items in charter milestones.
          2. Chairs: Announcements and Heads-Up
          2.1 Chairs: Other Drafts Related to TSVWG
              draft-olteanu-intarea-socks-6 - For info (Please discuss on INTAREA
              draft-leddy-6man-truncate - For info (Please discuss on 6MAN list)
              draft-eastlake-sfc-nsh-ecn-support - For info (Please discuss on
              SFC list)
          3. Transport and Network
          3.1 Roland Bless: Lower Effort PHB to WGLC
          The WGLC started end of May, but several reviews already on earlier
          versions. New comments from Brian Carpenter and David Black.
          Fred Baker had asked for discussion on updating RFC 4594.
          Fred B: If we are going to rev RFC 4594, there are quite a few things
          we would need to fix in association.
          David B: We should make just enough of an update to point to the new
          Fred B: I can make a 4594bis...
          David B: That can be valuable, but it is a can of worms.
          Fred B: I think we should enumerate the worms.
          David B: I think we should start with a draft that is contained in scope.
          Other changes to the LE PHB draft include adding "scavenger class",
          more history, and references.
          Need to still address Toerless's comments on multicast to avoid
          replication of LE packets to busy ports
          Suggested to include DSCP and Scavenger in the document title, not done
          so far in this revision.
          Issue of MISSREF needs to be resolved
          Going to submit a -06 version in the next week or so.
          Gorry F: It is worth calling out DSCP and Scavenger in the title to help
          people find the RFC.
          Brian Carpenter: When it gets to AUTH48, we can also add keywords.
          Gorry F: Regarding multicast, I think it would be good to include
          something, but the text should be limited to "if you're doing multicast,
          consider this...". This document does not need to specify everything,
          but make sure it is considered.
          Roland: Toerless has offered to help.
          Chairs: To conclude, this draft has already passed WGLC, and any new
          comments should be made to the WG.
          3.2 Tom Jones: Datagram PLPMTUD
          Updated requirements based on Magnus's feedback.
          Simplified black hole detection, etc.
          More figures to describe several aspects of the algorithm, updated state
          machine, etc.
          The terminology "effective path MTU" was too much to say, so we call
          it PLPMTU "packetization layer PMTU". Replaced ICMP verification with
          validation. We think validation is the correct words.
          David B: The changes look good. Will you or Gorry read this draft
          against the INTAREA tunnels draft to make sure they are reconciled in
          Gorry F: (as author) The terminology within the IETF is messed up - there
          are many different terms for slightly different things. As an author,
          we will refer to current RFC terms and look to the INTAREA draft to see
          if they can be reconciled. We will explain how the terms are used.
          David B: Good, I just do not want the same term used differently in both
          Ron Bonica: In INTAREA we have the same problem with a multiplicity
          of terms. It could be useful to have a terminology only document. Ron
          volunteers to do this.
          Tom: As long as you use our terms...
          Some key terms are: PLPMTU (output of algorithm), BASE_PMTU, MPS
          (application size), PROBED_SIZE, Actual PMTU.
          Update on feedback from Igor, Magnus, Timo. Mainly issues with the state
          The next rev will include changes to the text on  PTB processing (ICMP).
          With regards to QUIC, we have had a lot of discussion on PTMU in QUIC,
          and did some work at the IETF Hackathon. It is entirely possible using
          existing mechanisms in the QUIC protocol. Load balancers may need more
          state to handle PTB. Any QUIC probes that go to load balancers will need
          to carry both IDs.
          We will need to write careful text about error states and being resilient
          to broken networks. Targeting the November meeting for updates.
          Igor L: Thanks for working with us to improve this; with regards to
          error states, generally due to PTB that should not be the case, I would
          equate to bad ICMP in the network (destination unreachable that is not
          David B: One thing to consider is misconfigured tunnels, which is rare
          for IPv4, but more common for IPv6.
          Gorry F: An example of an error that can arise is when an endpoint tries
          to send a packet of size 1000, and the PTB reports a link MTU of ~700,
          but actually probing shows the path supports 1000 B packets. So there
          may be cases in which that *can* work.
          Another thing to announce is that we have several implementations that
          we are working on. Good to know there is code there. Let us know if you
          want to play with the code.
          Michael Tuexen: We also have implementation for UDP/SCTP.
          Chairs: We expect an updated draft soon, please discuss this on the list.
          3.3 Ron Bonica:  Destination Originates ICMP PTB Messages
          Sometimes ICMP PTB message cannot make it back, e.g., bad firewall
          filters (home routers), or other less common issues. An endpoint can
          see persistent black holes if the source does not update the PMTU.
          An ICMP PTB from the destination node is more likely to make it all the
          way through the network than an intermediary node.
          The ID adds a truncation eligible option and truncated packet option.
          Another option was suggested by TSVWG list, to indicate truncation
          eligibility and creates a large padded packet, and indicates how many
          bytes are not padding. The destination can check how much was truncated
          and how much useful data actually made it across. At least you learn PMTU,
          and you may get useful data too.
          Is this work interesting without the padding trick?
          Is the padding trick interesting?
          Tim Shepherd: Why the packet not dropped?
          Ron B: Because it has the truncation option...?
          Tim S: Well any legacy device would drop it right?
          Ron B: Good point, that is safe but not useful.
          David B: We should think more about incremental deployment.
          Igor L: If the packet makes it to the destination, some applications
          can certainly still use data even when truncated. For the assertion that
          the destination will be able to get ICMP back, we need to test that.
          Tom Jones: I think adding the proposed bits is required, because TCP
          doesn't have a length field, and relies on the IP header to know the
          TCP segment size.
          Ron B: I will update the draft with the extra option data.
          Tom J: There are many revs as a new draft, so will this settle down to
          be implementable?
          Mirja K (as individual): Why do we not we put the padding directly in
          the option? (The "bad idea" fairy brought this.)
          Ron B: The reason why is that the max size of padding is 255 bytes. So
          could not pad out to larger sizes.
          Michael T: A modified packet would be dropped with a bad checksum right?
          Ron B: The padding would not be protected by the checksum. Should the
          packet be correct before or after padding?
          Gorry F: I think we need to be really careful that the transport does
          not misinterpret the padding and/or accept truncated data - for TCP this
          may be more difficult that it first seems.
          --Open question on this, thoughts both ways.
          Fred B: You want the router to disobey current IPv6 processing in an
          RFC and then look at an option after the HBH option.
          Ron B: There is precedent for this in the RFC describing encapsulation
          Fred B: Also, you mentioned address-based NATs; also consider port-mapping
          Ron B: This draft does not specify how to communicate up to the higher
          Fred B: You will need to address that somehow.
          Al Morton: I was shocked to see that you would overwrite the extension
          header with another type!
          Ron B: This is, indeed, the stretch.
          Al: This makes me concerned about what the IESG could think!
          Ron B: It is a big deal to modify an extension header; as is
          truncation! Could be better than dropping?
          Bob Briscoe: On the topic of incremental deployment, we need a way to
          do this without losing the packet. Something like racing things. Looking
          at stats on dropping packets based on dest option, it's at 12-17%. Even
          if this is supported, it will have trouble getting through the network.
          Gorry F: This interesting to explore! Needs more thinking, I think
          solving the racing and transport issues are important - and that work
          seems relevant in TSVWG, and very related to PLPMTUD.
          3.4 Jana Iyengar: Transport mechanisms in QUIC (10 minutes)
          Sharing QUIC congestion control and recovery. Premise is that QUIC is
          different from TCP: send order is separable from delivery order; packet
          numbers increase monotonically; receiver states ack delay; communicates
          largest acked; and has different ECN signalling.
          Loss Detection has fast retransmit and early retransmit that look similar,
          but different. Has tail loss probe, which has not been finished for TCP.
          Currently doing editorial work, adding more rationale, etc. Will present
          more in TSVWG, TSVAREA, or TCPM in Bangkok
          Gorry F: We're not discussing QUIC protocol here, but we can take
          questions at the mic.
          Randall: If you look at the RACK draft, it does have Tail Loss Probe
          Michael T: Why not use RACK?
          Jana I: We could in theory. QUIC loss recovery covers RACK/is RACK. Covers
          time-based things. Because packet numbers increase in QUIC, that provides
          time ordering. Not exactly RACK for QUIC, but covered.
          Yoshi: Is this really NewReno, or something based on NewReno that's
          trying to go beyond or be better?
          Jana I: The loss detection mechanism is different, but the CC (I believe)
          is NewReno, with minor modifications.
          Jana I: CC uses NewReno but with largest_acked for the recovery period.
          3.5 Magnus Westerlund: Update on ECN in QUIC
          There was a design team for ECN in QUIC, and many changes via editing
          New ACK_ECN frame with counters for different marking types in the ack.
          Validates ECT on the path and processing on the peer endpoint.
          It does continuous validation of the values to deal with path changes:
          We do not want to falsely think markings are getting through.
          There are some outstanding issues for optimizing the ACK format; recently
          merged continuous verification; and open issue for lying receivers
          Q1: Can an attacker intercept packets and add markings from the side to
          mess with the congestion window. Requires beating the original packet,
          as long as only marking on original packets are accepted.
          Q2: Will you have ECT(0) and ECT(1) mixed in the same flow?
          David B: We need to see where L4S goes with the use of ECT(1).
          Bob B: The approach in AccECN is that the receiver is a dumb
          reflector. There is also the question of how quick QUIC deployment will
          be, as relative to TCP. If we allow both codepoints, we can upgrade more,
          we do not need to worry in the same way.
          I think you do need to report if you expect ECT(0) and you then get
          Jana I: You can have a complex ACK in QUIC, so part of the question is
          how we encode the bits to get the most accurate reflection back.
          Colin Perkins: The Internet have a history of devices that think they
          understand TOS; so we may see these bits transmuting into one another
          in some networks. So we should have a reporting mechanism around this.
          Magnus W: Agreed
          Q3: Detecting cheating/lying receivers. Could ignore reporting CE marks
          to get more capacity than honest receivers. The network could inject CE
          marks from the sender to validate that reports are indeed being made to
          detect the lie.
          Bob B: Is this detection a requirement?
          Magnus: Just an open issue, not merged yet
          Mirja K: (personally) I think any of these recommendations are not QUIC
          specific, but should be a separate document.
          Gorry F: That is one reason I asked for this to be here, so we can have
          a broad discussion of ECN apart from QUIC.
          Mirja K : I am not sure if the detection of lying is too useful,
          overall. A flow is still competing for capacity and CC should be designed
          to take care of this.
          Bob B: It has been suggested that you wait before replying to the CE
          (like strech acks) since you may be getting a lot of them.
          Gorry F: Please discuss on TSVWG list!
          4. Other presentations / New Work
          4.1 Colin Perkins/Gorry Fairhurst: Impact of Transport Header Encryption
          Transport protocols are beginning to use end to end encryption/integrity
          for the transport headers. Goals of the draft is to consider the impact
          on the way we deploy and design protocols.
          Three revisions since IETF 101; comments from many people; editorial
          improvements, and more security considerations.
          The editors are trying to provide a neutral and balanced discussion in
          the document, without judging encryption as a good or bad thing. Just
          explaining what is being done in operational networks and
          the impacts of encryption on this.
          Some comments were added about ossification and other reasons to encrypt
          the headers.
          Some notes added on implications of accountability.
          Also added a new security consideration section of the draft, discussing
          the implications of avoiding ossification vs exposing information. This
          summarised issues explained in the rest of the draft.
          There has been clear interest over the past 18 months in IETF WGs. This
          is thought useful to take a step back from the focus on QUIC, and look
          more broadly and apply general lessons. We believe this is useful to
          adopt as a WG draft.
          Jana I: Thank you for presenting; not read in detail in recent version,
          but definitely intending to read it. Good to see ossification text be
          added, since that is such a big part of encrypting the headers. May be
          good to list out things that are suffering right now, like TFO and MPTCP
          deployment due to middleboxes. These were direct motivators.
          David B: Do you think this draft should be adopted by the WG?
          Jana I: Is this informational?
          Colin: Yes, think so
          Jana I: The people working on QUIC should have a look at this and make
          sure experience is represented, then yes.
          Brian Trammell: Need to read this version of the draft too. I was of
          the opinion that this should be adopted. Continue to be so. How do
          you see this draft moving alongside IAB work on wire image and path
          signals? Should we be working together?
          Gorry F (from WG mic): I expect the IAB documents will provide guidance
          looking ahead...
          Brian T: We hope to.
          Gorry F: In contrast, this document will not provide specific IETF
          guidance, it documents issues and history and says what would change if
          practices change
          Brian T: The wire image ID actually refers to this one. I think wire image
          is close to done (sept/oct). Give feedback please. Path signals ID is
          actually older, but may be a bit more controversial, since it says that
          you must think about these items. This is the right WG for this document.
          Jabber: How much review and comments on the mailing list have you had?
          Colin: Gotten over a half dozen people giving feedback, and some detailed
          reviews. It has been presented
          at several IETF meetings in various areas.
          David B: Both authors of the referenced mm-encrypt draft also gave
          Mirja K: The more you go in the direction of being normative, the harder
          it will be to get consensus.
          Al Morten: I am glad to see the whole slide on neutral point of view. I
          support this draft going forward. I will do what I can to help.
          Spencer (remote AD): I was pleased to see this document just be
          descriptive from the transport perspective. Will help the document be
          Mirja K (as AD): As a background on the mm-encrypt draft, that RFC was
          AD-sponsored without consensus.
          Chairs (David): How many people read any version?
              Many hands
          Hum for adoption:
          Hum for not:
          Chairs (David): I believe we will adopt, the decision will be confirmed
          on the list.
          4.2 Eric Kinnear : TCP Encapsulation Considerations
          We presented this at IETF 101 in TSVAREA. It is about IKE in
          TCP. Expressed interest in general usage applicability. It is intended
          to be an informational reference for anyone trying to tunnel traffic
          over TCP.
          The primary thing we would like to hear from the WG is what are the
          other cases for doing this and any other pitfalls the WG may see.
          This document does not suggest putting TCP in TCP, does not suggest
          general use, does not modify TCP at all, or define a specific protocol.
          Motivations: UDP traffic can be blocked or treated badly by NAT
          timeouts. Are there others?
          Encapsulation Format: LV format; again, are there other suggestions? Also
          need to make sure you have a port.
          The main problem is performance concerns. What can go wrong, and how
          does a host may deal with it. Not all concerns have full mitigations,
          but it still identifies the problems.
          Two categories: added unreliability, and problems with TCP-in-TCP.
          Mirja K (as individual): Should we make a stronger recommendation to
          not try to modify your protocol on top?
          Eric K: That makes sense
          Terminology: "inner" flows and "outer" tunnel for both layers of
          TCP. Three concerns include:
           - Inner TCP experiences outer loss as a delay; delay based congestion
           control can help with that
          Brandon Williams: Similar issues were raised in the network coding
          research group. That work amplifies the use of delay-based CC. They're
          also experimenting with ECN in the inner flows.
          - Congestion window interactions and bufferbloat
          Bursts of packets created by retransmission, since any retransmission
          will be eventually a duplicate. No great solution other than being
          conservative for retransmissions.
              - Head of Line Blocking
          Any timeout on the other tunnel blocks all other flows. Again increasing
          the timeouts on inner flows helps avoid this.
          Gorry F: What is the problem with the extra set of segments retransmitted
          by the lower layer?
          Eric K: You are loading too many packets onto the network after the
          Jana I: We should use the word channel somewhere in here? If you control
          the tunnel endpoints, and how you packetize? You can pull the inner
          packets out of order.
          Eric K: We did some experiments in a lab and that did not help too much,
          but we should vary more parameters.
          Jana I: We do not want to make assumptions about the congestion control.
          Colin: We did similar for RTP stuff. We should reference those here. Looks
          like same wire format.
          Mirja K: Regarding the mitigation techniques, we need to distinguish
          between pure end to end, and tunnels for part of the path.
          Chairs: How many people read any version?
          Handful (6) have read document.
          Session II: Thursday Jul-19-2018 1810
          Note Taker: Tom Jones
          5. Transport Protocols and Mechanisms
          5.1 Michael Tuexen: SCTP Drafts
          NATs do not support SCTP in an efficient way. Same method for TCP and UDP,
          this gets hard with multihoming and multipath.
          Changing the port number needs support for SCTP, because it uses a CRC
          to protect the data.
          The document therefore specified a method for SCTP NAT without changing
          port numbers.
          Status: On 12th version. Comments addressed and text has been made more
          The document was not split into endpoint/middlebox as this did not make
          sense to make two separate sections.
          Authors consider it finished, but there are new comments on the
          organisation on the list from gorry, including a suggestion of how to
          reorganise the text to address endpoint versus NAT implementers. This
          will be addressed in the next revision and we then expect Gorry Fairhurst
          to comment again.
          Maksim Proshin: Are you aware of any NAT implementations that support
          Michael T: FreeBSD NAT supports an earlier version of this.
          Maksim P: Linux does not have this.
          Michael T: That is so.
          Maksim P: NATs can provide some support to SCTP already. I think it
          would be really good, if the draft describes what works or breaks for
          SCTP if a NAT does not support these new methods.
          Michael T: It is hard to describe a non-working NAT box.
          Gorry F: It would be useful to explain what happens when using a straight
          IP NAT that does not change ports.
          Michael T: Some NATs direct all unknown packets to a host. This works
          for SCTP.
          Randal Stewart: This ID explains how to support SCTP for NAT
          implementers. That is not to say what will
          happen if you do not support SCTP in a NAT. The BEHAVE working group
          would be a better place to specify that.
          Gorry F: The BEHAVE work was transferred to this WG when that closed, so
          this is the right place to discuss how the BEHAVE RFCs impact this topic.
          Maksim P: For SCTP implementers. I want to understand what will not work
          if you do not implement the specification.
          Gorry F: If you implement the SCTP extensions described in this draft,
          what happens if you just do the endpoint association and find an old
          fashioned NAT.
          Michael T: Normal SCTP can work through an IP NAT, and then SCTP
          associations might break if there are multiple endpoints behind the same
          Tim Shepherd: If packets get through that  NAT something interesting is
          going on.
          Gorry F: What we are calling a NAT will just map IP address if it does
          not understand the transport protocol.
          Tim S: OK, does that then send unknown packets to an endpoint?
          Michael T: I have no idea, how this behaves with two nodes behind the
          NAT. Normally the port number would be used to demux, but I have not
          thought what would happen.
          Gorry F: Could you please add some text in the intro to cover undefined
          Michael T: Yes, I can write some warning text.
          Chairs: We need people that understand NATs to review this document. Would
          anyone review?
            Maksim P and Kyle Larose will review
          Chairs: Editors, please submit a revision with this  and we will try to
          go to WGLC
          5.2 Michael Tuexen: RFC4960.bis
               Planning for draft-ietf-tsvwg-rfc4960-bis (now on Charter)
          rfc4960-errata has left the WG, as listing consensus on how to address
          the errata from SCTP RFCs in the bis document to be published.
          Not every issue here is being submitted to the errata system, and this
          presents a consistent view of how these are expected to be addressed.. Not
          the ones which are wrong or rejected.
          The IESG evaluation has a high number of abstains (this is informational)
          and the document is now
          with our AD (Spencer) to decide what to do next. There were comments
          that the document is hard to read, specifically because the changes are
          ordered by time and some update modify previously updated text.
          After looking at this, we think the draft can be made easier to understand
          for implementors and other readers. We plan to add a note after each
          comment that says whether this is the final proposed text, or text
          explaining this is further changed in a later section in the document.
          Gorry F: We have discussed this and as the document shepherd I would be
          happy with this change. I expect it will improve the readability, and
          address this particular set of comments. Please do this as soon as you
          are able, and I will speak to Spencer and Spencer will know what to do.
          Gorry F: Are you now planning to open a -bis document after this?
          Michael T: The plan until this morning was to submit a 00 identical to
          the RFC.
          Gorry F: Yes, this would an appropriate plan.
          Michael T: We found out RFC 4960 was processed in nroff, so we will
          see what we can do. Maybe submit 00, then submit an 01 with a modern
          Chairs: OK. I suggest you ask the RFC editor if you need help making an
          XML version (they may have tools).
          Michael T: We will submit -00 as working group document.
          5.3 L4S
              Bob Briscoe: ECN drafts
          There was no presentation about draft-ietf-tsvwg-l4s-arch this time.
          There is a new TCP-RACK-like requirement for a transport using L4S.
          The 'TCP-PRAGUE' requirements are updated so that the requirements include
          that any cc must satisfy to have the right to use this codepoint in the
          network. This signals that this cc is acting in a scalable way and won't
          cause a queue.
          We added a fifth requirement: Scalable CC must count in units time and
          not in units of packets.
          This allows L4S enabled-links to relax their reordering requirements. Some
          radio links bond multiple links together to increase bandwidth, relaxing
          the ordering requirements allows them to avoid slowing down to maintain
          packet order.
          Lossy links may need link layer retransmission, and currently that means
          a resequencing buffer at the far end of the link. If there is a hole
          in the sequence this causes head of line blocking. Allowing reordering
          within a certain time this buffer can be removed entirely.
          A "MUST NOT" was suggested here so the method can evolve over time. We
          will be stuck for 30 years if we do not allow this sort of change.
          Gorry F: I do not believe expectation of being stuck for 30 years! True
          there are hurdles to rapid deployment, and this is now an important
          consideration for the WG to consider.
          Bob B: How do you know which endpoints will enable RACK?
          Gorry F: I want to understand the "MUST NOT" as a chair. That is a
          significant change in IETF recommendation, and goes in a direction
          different to many existing transport specifications. There are
          considerations here that need to be explained to the WG, and the WG as a
          whole need to decide this, this is not just a "detail" for the authors.
          We also have to figure out sort of existing applications/protocols might
          work and what might not. I have concerns about the impact of tunnels and
          other transport constructions that may unwittingly expose apps to odd
          side-effects. As a WG we must first embrace this, and seek to understand
          the implications.
          Anna Brunstrom: Does rack not also respond to the first 3 reordered
          Bob B: This is why I say RACK-like, it could be something different to
          Anna B: Must not detect loss in units of packets, requires time from
          the start. RACK mixes this at the start. Yeucheng is going to reconsider
          this and discuss this in TCPM.
          Anna B: I thought the rule was there to help speed the time or detecting
          loss. He left that rule because it is hard to detect some patterns of
          loss otherwise.
          Bob B: It is because you do not have many packets in the first RTT,
          we are going to try and work it out.
          Chairs: There are things here that TSVWG needs to understand and
          think about - please do continue to ask for feedback and discuss the
          implications on the list.
          There was no time to discuss this, please send comments on the new text
          using the WG list.
          We have updated this draft. The main purpose is to introduce the idea of
          expedited forwarding in dual queue as well as ECN for non-queue building
          traffic like DNS or game sync traffic.
          We could consider departing the different concepts: Maybe all the other
          stuff in this draft can die or be separated out.
          Gorry F: Please talk offline with David about this
          Bob B: There is a group of people working on this, but I am acting as
          editor and it looks like it is only me. This will change in the next
          few weeks and we can start to progress. I will now try and get their
          comments on the list.
          Gorry F: Visibility to why and how will be very good. Will this be in
          Bob B: Yes
          Technical updates
          6. New Work
          6.1 Yingzhen Qu: IPv6 Reservation Protocol
          David Black: IETF has interesting experience with resource reservation
          protocols. Anyone doing this will find interesting path diversity issues.
          We want an in-band signalling protocol using a extension header.
          Meant only for flows with high bandwidth low latency requirements.
          Gorry F: The ETSI work items say it will publish a document in August. Is
          that still the plan?
          Yingzhen Q: Yes.
          Gorry F: Does the IETF have change control for the protocol?
          Yingzhen Q: The final document will be public.
          Gorry F: Is ETSI publishing further standards in the NCP group or that
          the end of this work?
          Yingzhen Q: We will collect information from the IRTF and see.
          Kyle Rose: There is an assumption about the number of flows and it is
          very small, what if a small number of flows tries to flood the network
          Yingzhen Q: We have authentication for the flow reservation.
          Bob B: The signalling can be authentic, but the nodes can be numerous,
          you need push back from the network.
          Bob B: I would like to see in this ID much more time spent on
          understanding why this did not happen before rather than assuming it
          was scalability.
          Gorry F: We do have a rich history in the IETF trying this. We cannot
          forget all the things we tried in the past with other protocols and what
          worked and did not. Many were used only in very specific use-cases. There
          are new opportunities now as hardware progresses and the Internet changes,
          but there are also things that seem very hard to get right.
          Yingzhen Q: In-band signalling is not new. The problem is that the
          signalling has to processed at almost line speed.
          Bob B: You need to look at all the reasons, not just scalability.
          I was heavily involved in the work to make this work with BT. It was
          used quite heavily for about 10 years then taken out because it had
          never once said no.
          Yingzhen Q: If you know all the pitfalls, we would be happy to change
          Bob B: This was a pitfall, at the time signalling just was not necessary,
          and we had standards to enable various styles of QoS. By the time you
          get through standards operators will have so much bandwidth for the
          things you currently think are large they will actually be tiny.
          Bob B: There are other reasons, RSVP applicability is only some of
          this. We at the IETF have all been burned by topic in the past.
          Yingzhen Q: This is not only about bandwidth reservation, it also includes
          queueing and scheduling.
          Bob B: So also did RSVP.
          Yingzhen Q: There are many mechanisms people are trying to use, and new
          ways to do this.
          Fred Baker: I would respond to Bob Briscoe. What where the issues the
          previous time this was proposed? It was proposed in 2005, and never made
          it to a WG. From a system design thing it just was not possible to build
          the system.
          Gorry F: I see there are people here to talk to, listen and also explain
          what can be done with new technology. There is some homework that must
          be done.
          Yingzhen Q: We will do our homework, and see whether we can build a new
          Gorry F: Getting multiple vendor inputs will really help, if you can
          get a few different to agree that will be huge.
          Fred B: At this stage, this could be a better topic for ICCRG?
          Gorry F: I agree. However, we need to be able to consider opportunities
          for a new signalling protocol, and when we understand this it definitely
          would fall within the Charter of this WG.
          David B: Right now, this looks like a reservation protocol not a
          congestion control (CC) algorithm.
          Fred B: If you are not doing CC, why are you doing the reservation?
          Yingzhen Q: There is also a separate CC draft, these two work together.
          Gorry F: Thanks for the presentation. Please continue to talk about this
          5.3 Joe Touch (Remote): UDP Options (postponed to later in the meeting)
          Discussion of timestamps and what is required for TCP.
          Tom Jones: Surely hosts can be required to support times, there has been
          a lot of work recently to support randomized TCP timestamps in Linux
          and freebsd.
          Tom J: Is the requirement for that a host be able to parse the timestamp
          option and not send it?
          Joe T: We need to look at the requirements.
          Tom J: I think discussing the TS reply, as a solution to the PLPMTUD
          need is wrong.
          Joe T: I think TCP could use the TS for this.
          Gorry F (as individual): We want a request-response mechanism.
          Joe T: We were going to put an identifier in the request and use the
          timestamp as the identifier, so that you can pair the requests and
          Gorry F: We want an identifier, and this has properties that are not in
          my mind what a TS offers.
          Joe T: I would like to avoid a separate request option and a response
          Gorry F:  I think we can spare two options.
          Joe T: If you are using it on a regular basis it is wasting a lot of
          Gorry F: That may be okay, the method will not use it a lot - probes
          to increase the PMTU need not be frequent. A probe message is always
          Joe T: Let us take that offline.
          Gorry F: I am going to suggest we talk offline and go through some of
          these issues.
          Gorry F (as Chair): We are after the session close, the WG has emptied
          out and the remote audio is not great. Is there anything else?
          Joe T: No other comments here.
          Chairs: That concludes the meeting, please do continue these various
          discussions on the list, and we hope to see you in person or remotely
          at the next IETF meeting.

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