transport - [transport] transport stuff from the IETF
Subject: Transport protocols and bulk file transfer
List archive
- From: Scott Brim <>
- To: Transport WG <>
- Subject: [transport] transport stuff from the IETF
- Date: Fri, 15 Mar 2013 09:39:02 -0400
- Authentication-results: sfpop-ironport04.merit.edu; dkim=neutral (message not signed) header.i=none
A lot went on, and I brought home some work:
* Lots of discussion about PIE (Cisco) and CoDel (Jacobsen/Nichols),
particularly with Fair Queuing. Both of these are tremendously
better than what's in endpoints today, and what they are arguing
about is how to make them even more tremendously better.
sfq-CoDel (stochastic fair queueing) is production in Linux
already -- we could deploy it in endpoints tomorrow. CoDel is
better across the wide area, PIE is better in data centers. Both
still need work but they are already excellent.
* SCTP-NAT is done. SCTP/UDP is done but what's missing is a Happy
Eyeballs like decision making mechanism, to decide between
SCTP-over-UDP versus native SCTP. Also I'm concerned about
layering without communication: running happy eyeballs functions
simultaneously for TCP/SCTP and SCTP[/UDP], in a TCP/SCTP shim
(very likely), in the kernel, and in the web browser? To be
sorted out. Dan Wing is going to try.
* The RTCWEB people chose to do SCTP over DTLS, not over UDP, for
security. The problem is that that pushes the happy eyeballs
decision up into user space (UDP is in the kernel). The claim in
RTCWEB is that DTLS will be in the kernel "someday" so it's okay.
We'll see.
* David Black (EMC): DSCP markings: there will ONLY be 4 defined
classes between carriers and all carriers will use them.
"guaranteed" (EF), "bulk inelastic" (AF41 - low loss, low delay,
low jitter at high bandwidth - traffic load must be controlled,
will avoid drops by AQM, may get bursty packet loss), "assured"
(AF31, AF32, AF33 - to transport traffic without bandwidth
requirements); and "default"/best effort.
* There's an idea of signaling an end-to-end SLA at the granularity
of the destination AS. I don't think this is very useful.
* Gorry Fairhurst: draft-ietf-tcpm-newcwv-00: rate limiting built
into TCP, instead of it pushing as hard as it can. Concerns about
how bursty it's going to be. Still twiddling pipeack estimation
and smoothing filters. Implementation will be ready in next few
months.
* There's now an Active Queue Management mailing list, since we're
trying to get organized about it.
* Gorry Fairhurst (U of Aberdeen) - follow up on building rate
limiting into TCP. Do some experiments. This fits well with rate
limiting TCP (using tc and a hierarchical token bucket).
* Jim Martin (Clemson): 3 topics: campus mobility services; Internet2
and an experimental R&E MVNO; and transport (he has consulted with
the cable industry on QoS issues for a long time). Will follow up
about possible collaboration.
* Bob Braden and Jim Gettys are compiling a "lessons learned" about
buffer bloat. Case studies. How to do better. I told him about
our problem with dropped packets.
* Benno Overeinder (NLNet labs, University of Amsterdam) was part of
the MPTCP-over-OpenFlow project, and he agrees that doing it as a
decoupled overlay wasn't so interesting, so he's working on better
integration between the layers, letting MPTCP have insight into and
control of OF. He wants to follow up with us. He will send some
research info.
* Benno will also send a paper on transport layer issues.
* Suresh Krishnan (Ericsson) says he's working on experiments with
OpenFlow and dynamically changing QoS.
- [transport] transport stuff from the IETF, Scott Brim, 03/15/2013
Archive powered by MHonArc 2.6.16.