ICCRG meeting, IETF 93, Prague Wednesday, July 22, 2015, 15:50-17:20, Congress Hall I Costin Raiciu: Three ways to (ab)use Multipath TCP Congestion Control, 20 min ---- Comment on slide by Stuart: Client is closer to AP1. Comment by Mirja: ECN is enabled; server need to support ECN -> Costin: or proxy from the audience (Tim): nice talk (applause) Si-Quoc-Viet Trang: FLOWER - Fuzzy Lower-than-Best-Effort Transport Protocol, 20 min ---- Mirja: did you try ledbat with slowstart?  Si-Quoc-Viet: yes, latecomer issue still happens Dave Taht: Thanking for citing this paper that we've done many year ago. Have you tried fq_codel and pie? With fq_codel it's unlikely. Michael Welzl: What are the next plans for this? answer: test FLOWER in real test bed and implement it in Linux kernel Emmanuel Lochin: ... and send draft to complement LEDBAT because we have many tests but Linux implementation is not stable yet Peter Szilagyi: Mobile Content Delivery Optimization based on Throughput Guidance, 20 min (related to draft-flinck-mobile-throughput-guidance and draft-sprecher-mobile-tg-exposure-req-arch). --- Stuart: assume loss if you have 30 hops in the Internet, the local node at the link knows most about the peculiarites of the link, is in the best position to know if it should be locally retransmitted Peter: If you have such mechanims on the path... Lars: has been proposed multiple times in the past, please focus on what's different here! Stuart: Comment that you've tried and it works, don't means that works everywhere. If every client would do this the Internet would collapse Peter: finds out what is the available bandwidth that is there and doesn't have to probe Stuart: Only work if you know that you are the bottleneck. If there would be a way to do this TCP would do this. Can set up a scenario that works, but that doesn't guarantee it works in all possible scenarios. Peter: that's true Gorry: you can do anything you like in the mobile access network. Your solution seems to be guiding traffic into different service classes Peter: you can increase the rate Gorry: is this only in controlled environment? Because there you can also do RSVP and control it completely. If this is an Internet spec, then how can we do this on the general Internet? Peter: You can't increase the rate at the source, can only decrease it Gorry: If we're doing an IETF spec, we want it to work in the Internet. What you seem to propose is only for controlled environment, where you can control all routers on the path? Jana: Existence proof doesn't show scalablility. We want something that is incrementally deployable and doesn't do harm. Is needs to fall back and this question has to be addressed. If incremental deployability collapses into using existing mechanisms such as DSCP and separating traffic into different service classes and so on, then this is what it is. This answer may not be enough and good, but it needs to be there. This idea has been there for at leat 20 years. Please cite this work and say why it's different. Lars: That's always happening when mobile people come to IETF. I haven't see what's changed here. This presentation could have been done 20 years ago. If anything has changed, I'm open to discuss this here Gorry: being positive: this is a problem that neeeds to be solved but maybe differently. Matt: What is different: mobile carriers injecting all sorts of performance-enhancing proxies and content is delievered from CDNs close to the user and in fact it's a closed envrionment. Huge data volume only traverses one ISP. These are two changes where now the previously not-useful non-scalable solutions have economic sense. Emmanuel Lochin: Non-Renegable Selective Acknowledgments (NR-SACKs) for TCP, 10 min --- Alex Zimmermann: Measure with Linux? But specification of RFC2018 is not implemented in Linux. If an RTO happens you don't restart and retransmit all the data. Matt Mathis: There is one MUST in 2018 that should have been a SHOULD, that the receiver clears the scoreboard upon a timeout. There's an errata against that one word in 2018. The reason reneging is in 2018 how it is is because of middleboxes that do incorrect things in the Internet, causing mistakes. If I have a NAT that is rewriting a connection which has got symbolic IP addresses in it, and rewrites IP addresses, the offset of the segment is different. The point of RFC2018 was to make it robust, efficiency was not the goal. There are devices that randomize sequence numbers but don't fix SACK blocks, so SACK blocks are out of the window. The argument to be made is not that this is more efficient but that the Internet is robust enough without that fallback. Jana: Brilliant example of designing the protocol to work with implementation bugs. Bugs are more entrenched now. Interesting to see if such bugs actually exist. Gorry: +1, do the experiment and tell us if it is a real problem Emmanuel: is a problem over satellite Gorry: listen to Matt's comment, get that right Manu: Argument that this is not needed has to be a statement that there are no bugs, which is hard to prove. I suspect it's not true. Gorry: and different with SCTP if you want to use that as an example, because of the way the streams work Bob Briscoe: Changing TCP for Short RTTs, 10 min --- Jana: this is the inability of TCP to send outside of an ACK clock Bob: yes, coming to that Matt: a lot of work done at some point on exhaustion, window sizes less than 1 Bob: lot of work on low rate side of it, but not low-rtt side of it Matt: but it doesn't matter how you get into that region Bob: agreed Bob: (different slide) don't use smaller packets Dave Taht: I totally agree on on everything else you're saying, but current hardware can handle packets well down below 300 bytes, so you can cut this packet size from a significant amount below the MTU Bob: you don't know whether you've got this hardware on your path. Jana: Spent much time thinking about this. Being able to pace is not easy in general, but mainly for large windows. Small windows it becomes substantially better. Packets are discrete and when windows are large that doesn't matter. Small windows, the fact that packets are discrete becomes a problem. You can start reducing the packet size, then it becomes easier to move it to the time domain. Bob: different from high speeds, here you're waiting a RTT and sending a packet after that, and so you're a lot safer Brian Trammell: ECN support beyond the Web: measurements from BitTorrent DHT, 10 min --- Dave Taht: this is good work; comment about data collection