Minutes for ICCRG at IETF-93
minutes-93-iccrg-1

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