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: None 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) The WG originally hoped the ECN encapsulation drafts would be out for June 2018, but we are moving those to Oct 2018. The L4S drafts aim for September, but chairs think this may be a bit optimistic and we want to push those out. The tunnel Congestion feedback will likely be adjusted in the Bangkok meeting. The WG is 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 list) 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 draft-ietf-tsvwg-le-phb The WGLC started end of May, but we have several reviews already on earlier versions. There are 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 DSCP. Fred B: I could 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. Qe still 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. the 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 draft-ietf-tsvwg-datagram-plpmtud the ID was updated requirements based on Magnus's feedback. This simplified black hole detection, etc. It added 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 terminology? 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 drafts. 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 said he could volunteer to do this. Tom: As long as you use our terms for these things, because these need to have specific meaning here ... 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 machine. 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 initial 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 plausible). 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 experience for UDP/SCTP that we will feedback to the ID. Chairs: We expect an updated draft soon, please discuss this on the list. 3.3 Ron Bonica: Destination Originates ICMP PTB Messages draft-leddy-6man-truncate 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 is an over-sized packet not just 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 max. Fred B: Also, you mentioned address-based NATs; also consider port-mapping NATs. Ron B: This draft does not specify how to communicate up to the higher layers. 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 it 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. It has loss detection with fast retransmit and early retransmit that look similar, but are different in the implementation. 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. Covers time-based things. Because packet numbers always increase in QUIC, that provides time ordering. This is not exactly RACK for QUIC, but teh principles are covered. Yoshi: Is this really NewReno, or something based on NewReno that is 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 ECT() codepoints, we can upgrade more, we do not need to worry in the same way. I think you really do need to report if you expect ECT(0) and you then receive a packet with ECT(1). 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 shown 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 draft-fairhurst-tsvwg-transport-encrypt 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. The ID 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 feedback. 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 published. 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: Many. Hum for not: Silence. Chairs (David): I believe we will adopt, the decision will be confirmed on the list. 4.2 Eric Kinnear : TCP Encapsulation Considerations draft-pauly-tsvwg-tcp-encapsulation 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 tunnel. 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 usage, and tunnels along a 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 draft-ietf-tsvwg-natsupp 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 consistent. 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 SCTP? 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 NAT. 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 NATs? 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 draft-ietf-tsvwg-rfc4960-errata Planning for draft-ietf-tsvwg-rfc4960-bis (now on Charter) The RFC4960-errata ID has left the WG. It lists consensus on how to address the errata from SCTP RFCs in the bis document. 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 a list of ones that were wrong or rejected. The IESG evaluation has a high number of abstains (this is proposed as 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. 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 toolchain. 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 a working group document. 5.3 L4S Bob Briscoe: ECN drafts draft-ietf-tsvwg-ecn-l4s-id draft-ietf-tsvwg-l4s-arch draft-ietf-tsvwg-aqm-dualq draft-briscoe-tsvwg-l4s-diffserv There was no presentation about draft-ietf-tsvwg-l4s-arch this time. draft-ietf-tsvwg-ecn-l4s-id 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 segments. Bob B: This is why I say RACK-like, it could be something different to RACK. 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. draft-ietf-tsvwg-aqm-dualq There was no time to discuss this, please send comments on the new text using the WG list. draft-briscoe-tsvwg-l4s-diffserv 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 Bangkok? Bob B: Yes. Technical updates 6. New Work 6.1 Yingzhen Qu: IPv6 Reservation Protocol draft-han-tsvwg-ip-transport-qos David Black: IETF has interesting experience with resource reservation protocols. Anyone doing this will find interesting path diversity issues. We propose 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 this. 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 technology. 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 offline. 5.3 Joe Touch (Remote): UDP Options (postponed to later in the meeting) draft-ietf-tsvwg-udp-options 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 responses. 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 option. 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 space. 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 valuable. Joe T: Let us take that offline. Gorry F: I am going to suggest we talk offline and go through some of these issues before Bangkok. 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.