- From: 陈智昌 <willchan@chromium.org>
- Date: Thu, 5 Sep 2013 13:30:11 +0800
- To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
- Cc: Joe Touch <touch@isi.edu>, Roberto Peon <grmocg@gmail.com>, Yuchung Cheng <ycheng@google.com>, HTTP Working Group <ietf-http-wg@w3.org>, tsvwg <tsvwg@ietf.org>
- Message-ID: <CAA4WUYg-_ku-kNVmjbeZzE=PniQg51w0vj8-5kd1F0kvewsm+A@mail.gmail.com>
Sorry for not being precise earlier and thanks for clarifying it. Agreed. On Thu, Sep 5, 2013 at 1:09 PM, Michael Tuexen < Michael.Tuexen@lurchi.franken.de> wrote: > On Sep 5, 2013, at 4:05 AM, William Chan (陈智昌) <willchan@chromium.org> > wrote: > > > I think it's a fine thing to support long-term solutions that aren't > immediately deployable, assuming of course that's the right long-term > approach. But I think it's a mistake not to deploy something in the > meanwhile. Let's not let the perfect be the enemy of the good. > > > > For example, I think it's great that SCTP can work over UDP. People may > argue that it should really be deployed in kernels, and it's probably true > that it'd perform better that way, but it's significantly more deployable > when you layer it on top of UDP. So I think it was a smart choice to deploy > rtcweb using SCTP over UDP, rather than arguing that we should wait for > SCTP/IP to be deployed in relevant OSes and NATs/intermediaries. > Just to be clear: You can implement SCTP/IP and SCTP/UDP/IP either in the > kernel or > in the application. For SCTP/IP some OSes require specific privileges, > most NAT boxes > don't support SCTP/IP. So choosing something like SCTP/UDP/IP allows for > deployment > within the application and make use of kernel implementations when > available. > Therefore, the crucial point is middlebox support which requires the UDP > encapsulation. > > Best regards > Michael > > > > > > On Wed, Sep 4, 2013 at 6:05 PM, Joe Touch <touch@isi.edu> wrote: > > > > > > On 9/4/2013 5:55 PM, William Chan (陈智昌) wrote: > > ... > > > > My point about TCP-AO is that it's not useful to continue to > > complain that something isn't widely deployed. If you need what it > > has, then why not start by helping deploy it? Then at least there's > > one less thing to complain about being missing in a few years. > > > > > > So I actually don't think my browser needs TCP-AO, so that's probably a > > bad example. > > > > Sure. > > > > > > But in any case, I don't know what I can do to help get it > > deployed. Are you suggesting I periodically email Microsoft to ask them > > to update their kernel networking stack to support it in their OS? What > > help would you like from me here? > > > > We need those who do need it in endsystems to either contribute code or > support others to code it. > > > > There was a long discussion in RPKI about the fact that router vendors > want it in host OSes (to run as RPKI servers), and who support it in their > routers. They spent a lot of time complaining that it wasn't available in > the host OSes, and a lot of time considering alternatives, rather than > either coding it up or supporting someone (anyone) who could. > > > > That has happened before with other extensions. It's not useful to claim > "it's not out there", especially when such a solution better or more > generally useful. I.e., claiming that "it has to already be deployed" is a > silly pre-requisite for *this* community; if it's that ephemeral a problem, > IMO it's not usefully solved here. > > > > Joe > > > >
Received on Thursday, 5 September 2013 05:30:38 UTC