Transport protocols are built over UDP these days - LTP, Saratoga, even DCCP and SCTP. That UDP goes underneath for convenience doesn't change the question about what services apps can be offered, and require - and UDP goes through all the NATs I'm familiar with in operation.
(Really looking forward to the UDP-Lite in UDP get-through-NAT document!) Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: [email protected] [[email protected]] On Behalf Of Joe Touch [[email protected]] Sent: 08 October 2013 21:15 To: Michael Welzl Cc: [email protected] Subject: Re: Call for participation: Transport Services Hi, Michael, et al., I find it difficult to resolve this with the fact that basically only TCP* gets through NATs, and the lack of widespread use of DCCP and SCTP. (* more specifically, transport "6" with a passing resemblance to TCP's header format, esp. SYN segments) I.e., what's the point in an app asking for what it wants if the only answer is "TCP"? This might be an interesting topic for a research prototype, but otherwise seems out of scope for the IETF - esp., as was noted, given the IETF's current 'appreciation' for the role of APIs in protocol design. Joe On 10/8/2013 4:57 AM, Michael Welzl wrote: > Dear all, > > Sorry if you receive multiple copies of this! I sent it to all the lists > with potentially interested folks... (this should be okay to do > according to RFC5434, which says "various mailing lists"). > > A community of interest is being formed to gauge whether there is > sufficient interest to host a BOF at the London IETF, on the topic of > "Transport Services". The intention is to create a WG that would define > the set of services that transport protocols offer to applications, such > that applications could at some point in the future request a service, > not a protocol. This could foster innovation (protocols could be tried > out, with a fall-back, without requiring the application programmer to > include such functionality); it could also give more freedom to whatever > resides below the API to automatically make the best out of what it > currently has available. > > If you're interested in this problem space, please visit the related > webpage that I have set up: > https://sites.google.com/site/transportprotocolservices/ > There you'll find an initial stab at a charter and all information about > the mailing list - please join us and participate in discussions! Thanks! > > Cheers, > Michael
