ICCRG meeting @ IETF 83 (Paris), Tuesday 27 March 2012 Chair Michael Welzl Note taker: Gorry Fairhurst * Congestion Control and Notification over Longer Time Scales and at Higher Layers - Dave McDysan  draft-mcdysan-iccrg-usecases-00 -: Are you looking at proxy devices close to the customer. This includes charging, etc. Ans: These things exist, but don't communicate to the customer. * Pre-congestion notification in mobile networks Sebastien Jobert draft-jobert-tsvwg-pre-congest-notif-mobile-00 Dirk Kutscher: Why do you think it is useful to use signalling interactions on the wireless network? Ans: If there is an application that can be delayed. you may wish to pause the service depending on the app. Dirk: A ZCO use could do this without knowing where the signals originate. ?: TCP middlebox (proxy that intercepts e-2-e connections) may be on the wireless side - who should notify the terminals. Ans: Would you propagate the ECN across the box? ?: This box is really to accelerate the TCP window growth. Toerless Echart: Was it a tunnel with flow control, or one with no queues? Ans: The tunnel could have rate control. but usually done higher in the network. Mirja Kuehlewind: TCP works on a longer timescale relative to the wireless channel. Ans: We really consider only whether a radio cell is congested or not. Mirja: The radio congestion can be on a very short timescale. Chair: Please take this discussion to the list. * Caching TCP segments Pasi Sarolahti Jana Iyengar: An application writes to a socket, and in TCP there is no message semantics, but this has the message semantics by applying to a specific set of bytes. Ans: Yes the stack adds the label with a start. Jana: This changes the semantics of the call. -: Rather like the Urgent pointer. Jana: The segment can be larger than a message. You can loose/gain ambiguous labels because TCP considers this a byte stream. There can be two segments with two hashes that are concatenated in a middlebox. Ans: Yes. Costin: This will not work if a middlebox sees ACKs without Data, who may try to reset the connection or fix the app. 1/3 of middleboxes had an odd response. Ans: Ok Costin: It needs application knowledge, we could do this higher in the stack. Michael Tuexen: This is not that efficient for TLS, etc. In how many cases can you use it? Ans: The interesting cases are multicast-like that replicate streams. Mirja: This seems on the wrong layer, it does not have to be in TCP, it's payload data. Ans: You need flow state. Jana: What can the network do with such data? * On the Fairness of Transport Protocols in a Multi-Path Environment Hakim Adhari (based on an upcoming ICC 2012 paper) Costin: In ideal resource pooling, the multiple links should appear as one big link. What you said applies if the congestion is in the core, whereas your scenario described was paying for more access bandwidth. Bob Briscoe: Rate fairness does not take account of time. Chair: This is a long story. Mirja: Were these emulator results? Ans: we implemented in Omnet++ Toerless: I still get more bandwidth from 2 service providers - The person who defines the TCP stack decides the policy. * End-to-End Transmission Control through Inference about the Network Keith Winstein http://conferences.sigcomm.org/hotnets/2011/papers/hotnetsX-final100.pdf Jana: The devil is as always in the detail - what exactly did you use? Ans: It is a machine learning method that is an active area of research. I don't have a global view. Jana: Is the simulator based on a network? Ans: No, it is a simple network model, that I showed in my slides. Chair: Please take this discussion to the list. * TCP Reno over Network Coding Nadia Boukhatem https://www.usukita.org/papers/5979/TA1_17_Chen_combocoding.pdf Bob: what causes TCP to stop? Ans: Random losses still cause timeouts. Matt: If the losses are fixed, something must slow down TCP, otherwise queues will continue to grow. At some points losses need to be sent to TCP, and we work on discriminating between random and network losses. Bob: Does the RTT still grow? Ans: Not really, these are wireless links. -: Have you compared with Westwood TCP? Ans: Not yet. * Research opportunities related to TCP Laminar Matt Mathis draft-mathis-tcpm-tcp-laminar-00 Jana: This seems to break down for the 1 MSS/RTT case. Ans: Many implementations of RFC 2018 do not clear the scoreboard (reneging), this causes a change - Timeouts go exponential, fractional MSS did not help this problem. Lars Eggert: Do you have a stack that implements this? Ans: Yes, but not running yet. Session 2: RTCWEB congestion control Topic chair: Harald Alvestrand * Introduction: The RTCWEB effort, and the traffic we expect to generate  Harald Alvestrand  draft-ietf-rtcweb-overview-02  draft-jesup-rtp-congestion-reqs-00 Gorry: Is 200ms a hard limit, i.e. do you intend it not to work on longer delay paths? Harald: It's the goal - but we know things work on longer paths (astronauts on the moon example), but we don't want to induce long delays. * Nice behaviour for RTP-based services  Varun Singh, Colin Perkins draft-perkins-avtcore-rtp-circuit-breakers-00 Matt: We may be seeking too much accuracy to build a circuit breaker. We should do something simple and go. Bob: Are you worried about killing your session before you need to? Ans: It is probably broken when you reach a high loss rate. This is really intended to stop unusable flows. Toerless: Should we break when a microwave is turned on to interfere with wireless? It would be nice to restart the flow. Ans: We have not talked about the details. Lars: It's good to avoid persistent overload. When do you retry? PWE3 is also an area that has long needed some form of CC. Cullen: Let's think hard. User experience is that it should not kill a call when you say "Hello is someone there?" - and the issue is people hit the denial once the circuit breaker trips. Lars: This is a user interface issue, when the user presses the "retry button". Cullen: Yes, but quick-retry is a common user reaction. * A delay-based congestion control candidate  Stefan Holmer  draft-alvestrand-rtcweb-congetstion-01 Bill: Can the receiver return information to find the bottleneck link? * Feedback mechanisms that might be useful  Harald Alvestrand  draft-alvestrand-rmcat-remb-00 Skipped. Charter overview and summary by Harald Alvestrand; final discussion: Lars: If you are a researcher or student in CC you should be looking at this. Mirja: Is this focussed only on media traffic? Harald: Our focus is interactive media traffic - if it were to work for YouTube it would be wonderful. Magnus: There are some RTP-based methods that may be self-fair but most do not really play "fair" with other traffic. We need to define algorithms for real-time interactive traffic. This is a real problem. Colin: +1. Bob: Are you interested in things that need something in the network? Harald: It must work without any network control. I expect ISPs to deploy methods to defend them against problems. David Dyson: Can we negotiate, adapt the codec rate? Harald: Yes, I expect this to be an important case. Matt: I expect for some users this will not be solvable - and the charter should mention this constraint. Harald: Agree. Lars: The hard part is to evaluate proposals like this, and this is not easy. Go build evaluation methods. We also need repeatable experiments. Colin: +1. We also need to be fair to the network and the result must be watchable. Following Bob, I think ECN should be used if available. The list has talked about this, and we are unlikely to get this right first time. Harald: It is important to know what needs to be done at the sender and receiver. Tim (R jessop via jabber): Media needs to adapt appropriately. (Jim Gettys) detecting loss can be important. Mirja: Can we look for more applications? Michael: Why are you not proposing new CCIDs? Harald: Because I don't believe in DCCP, because I did not see too much experience. Bob: I was thinking previously of the role of policers that may react to the traffic. Jana: If negotiable connection control is valuable, then why are we not looking at DCCP - since this is exactly what this adds over what is offered by UDP. Harald: There may be some unnecessary extra mechanisms. Stefan: Don't you loose information using DCCP? Colin: No, RTP is carried in DCCP. Harald: This is a question with multiple opinions. Please continue this discussion on the mailing list. End of Meeting.