TY - JOUR
T1 - On the usability of transport protocols other than TCP
T2 - A home gateway and internet path traversal study
AU - Bari, Runa
AU - Welzl, Michael
AU - Fairhurst, Gorry
AU - Elmokashfi, Ahmed Mustafa
AU - Dreibholz, Thomas
AU - Gjessing, Stein
N1 - Supplementary Data S1. Supplementary Raw Research Data. This is open data under the CC BY license http://creativecommons.org/licenses/by/4.0/
PY - 2020/5/22
Y1 - 2020/5/22
N2 - Network APIs are moving towards protocol agility, where applications express their needs but not a static protocol binding, and it is up to the layer below the API to choose a suitable protocol. The IETF Transport Services (TAPS) Working Group is standardizing a protocol-independent transport API and offering guidance to implementers. Apple’s recent “Network.framework” is specifically designed to allow such late and dynamic binding of protocols. When the network stack autonomously chooses and configures a protocol, it must first test which protocols are locally available and which work end-to-end (“protocol racing”). For this, it is important to know the set of available options, and which protocols should be tried first: Does it make sense to offer unchecked payload delivery, as with UDP-Lite? Is a UDP-based protocol like QUIC always a better choice, or should native SCTP be tried? This paper develops answers to such questions via (i) a NAT study in a local testbed, (ii) bidirectional Internet tests, (iii) a large scale Internet measurement campaign. The examined protocols are: SCTP, DCCP, UDP-Lite, UDP with a zero checksum and three different UDP encapsulations.
AB - Network APIs are moving towards protocol agility, where applications express their needs but not a static protocol binding, and it is up to the layer below the API to choose a suitable protocol. The IETF Transport Services (TAPS) Working Group is standardizing a protocol-independent transport API and offering guidance to implementers. Apple’s recent “Network.framework” is specifically designed to allow such late and dynamic binding of protocols. When the network stack autonomously chooses and configures a protocol, it must first test which protocols are locally available and which work end-to-end (“protocol racing”). For this, it is important to know the set of available options, and which protocols should be tried first: Does it make sense to offer unchecked payload delivery, as with UDP-Lite? Is a UDP-based protocol like QUIC always a better choice, or should native SCTP be tried? This paper develops answers to such questions via (i) a NAT study in a local testbed, (ii) bidirectional Internet tests, (iii) a large scale Internet measurement campaign. The examined protocols are: SCTP, DCCP, UDP-Lite, UDP with a zero checksum and three different UDP encapsulations.
KW - Internet
KW - Protocol testing
KW - SCTP
KW - DCCP
KW - UDP-lite
KW - NAT
KW - internet
KW - UDP-Lite
UR - http://www.scopus.com/inward/record.url?scp=85082134376&partnerID=8YFLogxK
U2 - 10.1016/j.comnet.2020.107211
DO - 10.1016/j.comnet.2020.107211
M3 - Article
VL - 173
JO - Computer Networks
JF - Computer Networks
SN - 1389-1286
M1 - 107211
ER -
