W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: [tsvwg] The List (of application-layer desired features)

From: 陈智昌 <willchan@chromium.org>
Date: Thu, 5 Sep 2013 13:30:11 +0800
Message-ID: <CAA4WUYg-_ku-kNVmjbeZzE=PniQg51w0vj8-5kd1F0kvewsm+A@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:15 UTC