IETF-68, Prague, CZ TSVWG *DRAFT*WG Minutes* Wednesday March 21st, 2007 0900-1130 Congress III Thursday March 22nd, 2007 1510-1610 Congress II ***NOTE: any presentations NOT completed on Wednesday will move to the Thursday session for presentation to the WG WG Chairs: James Polk Magnus Westerlund Lars Eggert Chairs Agenda Bashing 0900-0915 NOTE WELL x Document Status and Accomplishments Noticed a few errors - one regarding the status of a few IDs (that should be RFC) There was also a question about whether RSVP Emerg was WGLCd - which the chairs believe happened, but the WG doesn't remember seeing Milestones Review Active WG Documents: * Francois - RSVP Proxy Approaches - Presented draft-lefaucheur-tsvwg-rsvp-proxy-00.txt - Accepted as WG document - Agreed to split into two documents A) one I-D containing description of RSVP Proxy concepts, approaches and use cases --> Informational Track B) one I-D containing specification of small RSVP extensions for the “Path Triggered RSVP Receiver Proxy” --> Standards Track - Taxonomy of Proxy Approaches: - Path-Triggered Receiver Proxy - Path-Triggered Sender Proxy for Reverse Direction - Inspection-Triggered Proxy - STUN-Triggered Proxy - Application-Signaling-Triggered On-Path Proxy - Application-Signaling-Triggered Off-Path Source Proxy - RSVP-Signaling-Triggered Proxy - no questions * Francois - RSVP Proxy Protocol http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-proxy-proto-00.txt - this one is standards track - discusses a RSVP Receiver Proxy for endpoints that are not RSVP capable (or enabled) - Changes since draft-ieft-lefaucheur-rsvp-proxy-00: - Extended to cope with all relevant reservation errors (not just CAC reject) - Errors which sender can attempt to correct: send exact error code back to sender (e.g. CAC reject) - Errors which sender has no control over: send new “Unrecoverable Receiver Proxy Error” code - Extended to also cope with failures on RSVP Receiver Proxy node itself (in addition to failures upstream resulting in ResvErr) - Added text on behavior depending on reservation style: behavior for FF and for SE , WF not supported - Added text on Multicast - Added detailed text on how to build Session, Sender_descriptor and Error_Spec objects of PathErr - no questions * Bruce - A Proposal to Incorporate ECN and PCN in MPLS http://www.ietf.org/internet-drafts/draft-ietf-ecn-mpls-00.txt - copy rather than reset ECN at MPLS ingress ¹ RFC3168 ECN tunnelling - RFC3168 only said reset because security folks thought copy might leak info - concern has been resolved – updated IPSec RFC4301 (Dec 05) copies ECN at ingress - RFC3168 tunneling section needs updating to reflect later security thinking and practice - prove ECN will be useful in MPLS before adding it - ECN enables congestion control without need for drop - for optional RFCs (cf Diffserv in MPLS) vendors can decide if RFC is useful, not IETF - operators may want VPNs and constraint-based routing AND Diffserv/ECN capabilities - why put a function already in a higher layer in a lower layer? - congestion info travels from lower layers upwards – physical resource exhaustion - if don’t have ECN in MPLS header, LSR has to mark IP header to do ECN - don’t believe droppable data will decrease if ECN becomes widespread - clarification to be added: “droppable” means “to be dropped on MPLS decapsulation” - because outer MPLS header congestion marked but inner IP header not ECN capable - no questions * Fred - An EF DSCP for Capacity-Admitted Traffic http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-admitted-voice-dscp-00.txt - Section on PCN issues replaced with text from Kwok - This did not include his proposed blessing of pcn mechanisms as a drop-in replacement for signaling in all cases; I don’t believe that. - This did include updated references for pcn drafts - Request codepoint for video - Telephony Service Class - Multimedia Conferencing - Argument for a second “voice” class: - Voice on IP using no CAC or H.323-equivalent CAC widely deployed - To get bandwidth CAC, we have to allow for existing deployment and protect ourselves from it - (he's) not sure that is true of Video - Why not just add a requirement for bandwidth CAC on existing video class? - rather go back to RFC 4594 * Jozef asks: we have video deployed and coming, don't we need a new one for video too? * Dave McDyson: video may fit better with Francois's RSVP approach; marking are being done based on 4594 * Bob: wants to tease out hard CAC vs. soft CAC. * Fred: * Question: wondering why this is defining DSCPs and is informational * Fred: that decision is not his * Jozef: comment about rate adaptive * Fred: is concerned about the slower and slower throughput being adaptive for voice is good or not; general feeling is this is not desired Poll: is there a desire for a separate DSCP for video: ~15 hands yes 0 hands no Individual Submissions: * Janet - Performance Evaluation of EF-ADMIT http://www.ietf.org/internet-drafts/draft-gunn-tsvwg-ef-admit-evaluation-00.txt - have observed (through measurements) sustained traffic a 10 times offered load, which is a concern - looking at the 2 queue model vs. 1 queue model - Access line speeds- 256 Kb, 1.5 Mb, 45 Mb - EF-ADMIT traffic is small compared to EF traffic (10% of base EF) - Baseline traffic mix includes EF/EF-ADMIT (Voice), AF1 (Video), AF2 (Data) and BE (Data) - Network Control traffic modeled as AF2- and is protected by EF policing - Baseline (overall) approx 80% utilization for 256 Kb, 1.5 Mb - Baseline (overall) approx 55% utilization for 45Mbps - 10X Overload applies to all except the EF-ADMIT and AF2 traffic - Policing - Regular” EF policed to approx 50% of line speed, - No policing on AF and BE - Primary Scenarios (for each speed) 1EF, 1Q (current operation) 2EF, 1Q 2EF, 2Q - Secondary Scenarios- only for higher speeds - Mix Voice and Video in the EF-ADMIT stream - in the 256kbps case - Delay and jitter for EF not relevant because only 10% of the packets for each call get through - For EF-ADMIT, delay is better for 2Q (14 ms vs. 23 ms), jitter is about the same (50 ms) - Drop rate almost identical for 1Q and 2Q - in the 1.5Mbps - Delay and jitter for EF not relevant because only 15% of the packets for each call get through - For EF-ADMIT, delay and jitter are both below 10 ms, for both 1Q and 2Q - Introducing EF-ADMIT video worsens delay and jitter for both EF and EF ADMIT- slightly worse for EF-ADMIT with1Q (5ms delay, 16 ms jitter) - Drop rate almost identical for 1Q and 2Q - in the 45Mbps - Delay and jitter for EF not relevant because only small % of the packets for each call get through - For EF-ADMIT, delay and jitter are both below 1 ms, for both 1Q and 2Q - Introducing EF-ADMIT video has little effect on delay and jitter for both EF and EF ADMIT - Drop rate almost identical for 1Q and 2Q - Simulation and analytical results confirm the expectations described in draft-ietf-tsvwg-admitted-realtime-dscp-00 - When EF traffic is properly policed, the EF-ADMIT traffic is protected from the effects (dropping, delay, jitter) of a major overload of EF (and AF, etc.) traffic - When EF traffic is properly policed, the 1Q and 2Q cases perform very similarly if all the and EF and EF-ADMIT is Voice (short packets) - When video (long packets) traffic is introduced to the EF-ADMIT traffic, delay and jitter suffer at 1.5 Mbps- little impact at 45 Mbps - These results demonstrate significant value in preserving EF-ADMIT performance even when overload significant causes degradation of EF performance. - In the context of essential network services for disaster response (as addressed in IEPREP), we conclude that EF-ADMIT can help ensure that disaster response service is assured under all circumstances - next steps: - mixing signaling in - look at different rates than 3 given * Dave offered that voice and video are not mixed and need to be in separate DSCPs * Gorry - MIB for the UDP-Lite protocol http://www.ietf.org/internet-drafts/draft-renker-tsvwg-udplite-mib-01.txt - Linux 2.6.20 UDP-Lite for IPv4/IPv6 - MIB shares basics with UDP-MIB (RFC 4113): – InDatagrams, NoPorts, InErrors, OutDatagrams - New in UDP-Lite MIB: – InPartialCov – InDatagram with partial coverage – InBadCoverage – InError with bad coverage value – InBadChecksum – InError due to failed checksum – OutPartialCov – OutDatagram with partial coverage – A new endpoint table - Changes in rev -01 - All counters are now 64-bit counters - Fixed minor NiTs with formatting and definitions * Question - why move to 64 bit counters? The issue is 64 bit counters are typically for where wrapping occurs within an hour, and this is not true with error counters, so think about making them 32 bit * Anders - MIB for TCP and UDP processes http://www.ietf.org/internet-drafts/draft-persson-v6ops-mib-issue-01.txt - Paul Schauer spoke for Anders - Only ONE process can be associated with a given connection - Some systems allow multiple processes to shared a connection - System might only have information about the process that created the connection, which might be different from the process currently using the connection - Might be useful information, but no way to present it - Create a new table that maps one connection to possibly many process ids - INDEX made up of connection tuple and a PID - Augment Connection/Listener tables with creator PID and creation time - Questions to WG: - Is this an issue that needs to be addressed? - Is our approach reasonable? * Gorry: asking if this should be a WG item, or should there be a UDP-Lite MIB to this as well? * Dave: extensions to RFCs need to be in a separate doc, but to UDP-Lite, since this is an ID still, the UDP-Lite ID can be changed * Gorry thinks the UDP-Lite ID is done, so he's hesitant to add this text * Lars - UDP Guidelines http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-udp-guidelines-00.txt - some discussions recently with APP area document authors on UDP usage - there are some caveats of using UDP that are obvious to TSV folks, but maybe not to others - this document attempts to capture these guidelines for easy reference - nothing in this document is new (to TSV folks) - topics: (1) congestion control - congestion control, message size determination and reliability are difficult to get right - apps doing UDP bulk transfers should use TFRC or TCP-like windowing - apps that send a small number of messages should maintain an RTT estimate and limit themselves to 1 outstanding message per RTT - loss looks like long RTT sample - apps that can’t maintain an RTT estimate should use a conservative fixed timer and exponentially back it off under loss - e.g., 500ms, such as SIP & GIST - apps that can’t detect loss should use a more conservative fixed timer - e.g., 3 seconds, such as TCP SYN retransmit (2) message sizes - apps should not send messages larger than the path MTU - either implement path MTU discovery - or use IP-layer path MTU information - or don’t send anything larger than the minimum path MTU - IPv6 - 1280 bytes - IPv4 - min(1st-hop-MTU, 576 bytes) (3) reliability - apps should be aware that UDP does not provide - reliability - duplication protection - reordering protection - apps should be robust in the presence of such events - apps should use TCP, SCTP or DCCP whenever they can - if used correctly, more featureful transports aren’t as heavyweight as often claimed - if you can’t use those transports, use UDP according to the rest of these guidelines * Gorry - there doesn't seem to be guidance when tunnels are involved, i.e. what's safe to assume? * Lars doesn't have a number to put in, looking for help here * Michio - Fast Handover with SCTP on Single-home nodes http://www.ietf.org/internet-drafts/draft-micchie-tsvwg-fastmsctp-00.txt - Indication of handover issues in current Mobile SCTP - When “ADD IP ADDRESS” is sent ? - Proposition: Immediate after the notification of a new IP address - When does MN recover data transfer after the reception of ASCONF-ACK ? - Proposition: Considering handover event as change of communication Path - How does MN make CN retransmit DATA chunks to new address immediately ? - Proposition: New ASCONF parameter: “RECOMMEND RETRANSMISSION” - Indicating handover issues in the current Mobile SCTP - Especially, MN is single-homed - Single-homed MN disconnected during the handover process - Propose elements to achieve smooth transport layer handover - Immediate transmission of ASCONF - MN restarts data transfer immediately after the reception of ASCONF-ACK - Considering handover event as change of communication path - Restart of data transfer is performed with slow-start algorithm - Recommend Retransmission ASCONF parameter - make CN retransmit unacknowledged DATA to the specified address * Randy thinks this may be a good idea, but is still processing it. Concerned about congestion creation. * Lars - need more evaluation before moving forward * Michael - Avoiding Interactions of Quick-Start TCP and Flow Control http://www.ietf.org/internet-drafts/draft-scharf-tsvwg-quick-start-flow-control-00.txt - about what was noticed during Quickstart testing and evaluation - Flow Control Issue #1: Buffer Allocation - Quick-Start only effective for immediate large receiver buffer - Reasonable buffer size can be determined from approved rate - Recommendation for modified buffer allocation - Flow Control Issue #2: RWND Scaling - Problem: RFC 1323 Window Scaling - Window scaling required when receive window is larger than 65kB - BUT: "Window field in a SYN (i.e., a or ) segment itself is never scaled." - Maximum receive window of 65kB in and - Consequences for Quick-Start - If Quick-Start is included in segment - At most 65kB sent during rate-pacing phase - Maximum congestion window after Quick-Start phase is 65kB - No problem otherwise - Possible Solutions 1. Scale RWND with Quick-Start options, thus violate RFC 1323 (which is bad) 2. Signal true value of RWND, if required (which is the recommended course of action) - Conclusions - TCP flow control should be optimized when using Quick-Start - Possible interactions 1. Currently deployed buffer size auto-tuning mechanisms 2. RFC 1323 window scaling signaling - Not discussed in RFC 4782 * Magnus - Errata doesn't work so well, so that shouldn't be done * Lars - this is exactly what we want from experimenting from an experimental RFC * Comment - modifying 1323 would create interoperability problems. Perhaps a new TCP option number is a choice * Gorry - Quick-Start for DCCP 12 x http://www.ietf.org/internet-drafts/draft-fairhurst-tsvwg-dccp-qs-00.txt - Similar to QS with TCP [RFC 4782]. - Sender MAY use a Quick-Start request: - At start of a connection. - In the middle of a connection. - SHOULD send the request on a packet that requires an acknowledgement (DCCP-Request, DCCP-Response, or DCCP-Data). - MUST NOT make a subsequent Quick-Start Request within four RTTs. - CCID-3 responds slowly to changes. - Unlike TCP, TFRC receives a feedback once per RTT. - Add a new Quick-Start Validation Phase. - Period to affirm capacity used by QS packets did not introduce congestion. - Sender tentatively permitted to continue sending at QS-sendrate. - Limited to a maximum of 1.5 RTTs (or loss, or feedback for QS Packets) - At the end of the Quick-Start Validation phase: - Sender stops using the QS-sendrate. - Uses the standard congestion control mechanisms. - If no feedback received within Quick-Start Mode or Validation Phase: - MUST return to minimum of original rate (at start of QS Mode) and one half of QS-sendrate. - If a feedback packet arrives reporting packet loss - MUST immediately leave the Quick-Start Mode or Validation Phase. - Enters congestion avoidance phase. - Which WG does this belong? TSVWG or DCCP? * Lars - independent transport question - what happens with QS during idol periods? * Magnus - is it possible to use another mode while in QS mode? * Gorry - no * George's - RSVP User Error http://www.ietf.org/internet-drafts/draft-swallow-rsvp-user-error-spec-01.txt - Motivation: - RSVP takes a minimalist position on error reporting - In many cases it is difficult to anticipate which errors might be worth reporting - In development testing and interop testing there are more cases where some error information is useful than in actual production code - Desirable attributes - Allow coders to independently allocate error codes that they fell would be useful in their development - Allocation at the organizational or sub-organizational level - Organization identified by Enterprise Number - Backward compatibility - Generic error code to satisfy requirement for an ERROR_SPEC object - User_error_spec - Assignment is requested from the range 192 through 247 (max 256) - The node should ignore the object but forward it, unexamined and unmodified... * Ronan - likes the idea, but wants this to be optional within the protocol * George - it is optional HUM to adopt as WG item ~ 20 hands yes 0 hands no Bob announced his re-ECN Bar BOF to day at 1510 Ended first session 10 minutes early * Pasi's - Cross-layer Indications for Transport Protocols http://www.ietf.org/internet-drafts/draft-sarolahti-tsvwg-crosslayer-01.txt Focusing on mechanisms that require network interaction - Classification of cross-layer communication mechanisms - Past work - Not going to be a full research index of all past work - Focusing on IETF work (BOFs, Internet Drafts, RFCs) - Referencing selected interesting papers - Description of known problems - Discussion of possible future steps - Wrote up the missing parts from 00 - More detail about IP tunnels, references to related work - Reorganized taxonomy - Clarified scope - Multicast out of scope - Off-path signaling/notifications out of scope - Defined terminology - Looking for - Positive/Negative signals about the document: is it useful or not? - Specific comments about content - Guidance about the next steps - To do for the next version: - Add some missing references to related work - More discussion on ICMP - Should this be a TSVWG working group draft? * Lars - The goal would be informational * Pasi – Yes * Joe Touch – Removing off-path signaling is a mistake. Need to understand how off-path is working. For example tunneling look like off-path mechanism. - Previous BOF and failed efforts are interesting but not necessarily needing WG and community editing. Seems like an individual submission doc. * CSP – Don’t think the history part is necessary an IETF document. Interesting but not useful. * Elwyn – Seems to be a useful document. Something that can be expanded to give recommendation and making it more interesting an IAB. * Joe Touch – Not having written down what was tried results in other trying and make same mistakes. The reason to publish it in IETF is that it can be done here. Suggestion to keep here * CSP - [missed this comment] * JT - Seating the document in TSVWG is fine. As we don’t make recommendations it will be more efficient to not have it be a WG item and save time. * Magnus – Can be an AD sponsored and announcing it TSVWG is fine. * Sally - Specifying New Congestion Control Algorithms http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-cc-alt-00.txt - What is the problem? - There are many proposed congestion control mechanisms. - Some TCP implementations use congestion control that has not been through IETF process. - E.g., Linux and BIC TCP. - Goals: - Encourage new congestion control mechanisms to go through IETF review - Give guidelines for considering congestion control mechanisms for Experimental status. - Numerous changes based on feedback from Microsoft's High-Speed TCP workshop and within the WG - Added a section giving guidelines for requirements necessary for approval for deployment in the global Internet: - Guideline #1: impact to flows using standard congestion control - Guideline #3: investigating across a range of scenarios - Guideline #4: protection against congestion collapse - Guideline #8: consider deployability - New congestion controllers should be robustness to: - various queuing strategies - middleboxes - Changed the fairness guideline - new congestion controllers are expected to assess the impact on standard congestion controlled flows - do not comment on how this assessment should be conducted - removed some examples - which could be viewed as blessing one way to conduct the Assessment - Authors are not aware of remaining unaddressed items - Additional comments? - Ready for WGLC? * Joe Touch – One of the things that has affected cc specification. Has been the lack of description on how to write things done. Like to know if state machine, header and behavior. * Lars – No, we don’t but it was discussed in ICCRG. * JT – Does this need to be in a separate doc. * Lars – Not clear, depends on number of pages * JT – 5 pages * Tim Shepherd – Spent a lot of time in ICCRG without being able to tie down details. * Mark Allman: Joe should write text; this is beyond CC as he says and so outside the scope of this document * Joe – This is in an informational hint on what they should look at. Without being a template. * Lars – does this affect the WGLC? * Joe – No, unless there is text like what I need already that would result in issues. * Bob B – Why can’t we only write: Explain how it affects the CC architecture (RFC2914). * Lars - Need to be clearer on what needs to be said. * Joe – Lets add a note that makes it clear that this document explains that people are answering how it fulfills 2914. * Mark Allman – I agree that this will be useful * Lars – Lets consider this a WGLC comment. - 5 people had read the doc - Volunteer to review in WGLC. Joe Touch Elwyn Davids * Bob's - Flow Rate Fairness: Dismantling a Religion www.ietf.org/internet-drafts/draft-briscoe-tsvarea-fair-01.pdf - - Around 10-15 had read the document or the previous version * Gorry – This is not ready for WG item yet. I want to be certain on what the document is about. Isn’t the roadmap confusing and should be separated from the rest. * JT – Appears this is several documents. A short document saying that there are alternative ways of doing congestion control. There is another that contains the motivation. The roadmap does not belong in the IETF document at all, instead they belong to a charter or similar project control doc. * Tim Shepherd – This document helped reduce my confusion. Should publish this somehow * Mark Allman: saying that 'we don't have fairness now' is not quite right. we don't have perfect fairness. but, we could get MUCH worse. so, saying that we do not have to transition is sort of bogus, i think. * Gorry, [missed the comment] * Lars – this affects more than a single WG. This needs to done on a IETF wide scale. We are bit lost on how we could move forward.