- From: Tim Wicinski <tjw.ietf@gmail.com>
- Date: Fri, 4 Mar 2016 20:05:31 -0500
- To: Mark Nottingham <mnot@mnot.net>, Joe Touch <touch@ISI.EDU>
- Cc: Patrick McManus <mcmanus@ducksong.com>, Willy Tarreau <w@1wt.eu>, HTTP Working Group <ietf-http-wg@w3.org>
DNSOP recently went through the process of updating RFC5966, "DNS Transport over TCP - Implementation Requirements" and it was published just this week as RFC 7766 https://datatracker.ietf.org/doc/rfc7766/ There was a lot of effort put in this document to reflect current technology in TCP, like Fast Open. I support adoption, but I also think the document needs work. I'll be happy to assist and make it look less like a list of linux kernel tunings, tim On 3/4/16 5:56 PM, Mark Nottingham wrote: > Everyone, > > A significant amount of IETF time and effort has been spent recently on trying to make sure that transport and application work is well-aligned; especially, that transport decisions are made with input from actual applications folks and vice-versa. > > I've had encouraging discussions in the background with the transport ADs and others about coordinating to assure that this work -- if it gets taken on -- will help in those efforts. Right now we're figuring out exactly how that will occur, but suffice it to say that we won't be moving forward on this document until after B-A. > > In the meantime, I'd encourage everyone to view this as an opportunity to learn more about how TCP is used by applications, and to learn more about how applications can get the most out of TCP. The discussion so far has been illuminating, please continue. > > With regard to where the work is done -- that's certainly one of the things that we'll discuss, but I'll observe that while discussion about changing TCP should certainly take place in TCP-related fora, it's not reasonable to say that discussion about how applications *use* TCP can only happen there. > > With regard to the advice found on Google -- I think the point here is to provide an authoritative source to counter the misinformation out in the community. The document we're considering may not be in a suitable state to do that, but I'm confident we can get it there with appropriate participation. > > Joe, you also said: > >> The value would be in exploring the literature on the subject of designing large servers. > > > That is certainly *a* place we could find value. However, it is not the only place, and we're lucky enough to have a community of people on this list who develop and deploy some of the largest HTTP implementations (client, server and proxy), so I suggest it'd be best to consider them a source of value too. > > Cheers, > > >> On 5 Mar 2016, at 5:21 AM, Joe Touch <touch@ISI.EDU> wrote: >> >> Popping back up to the main point: >> >> - there is very little in this doc that is specific to HTTP >> >> there is a lot of good advice in the literature >> about how to implement big servers (incl. TCP-based), >> and there is no good reason to try to condense that into >> an RFC >> >> - the advice in this doc is often at odds with existing TCP advise >> >> Advice on changing/configuring TCP ought to happen on TCPM >> or TSVWG, not here. >> >> IMO, the doc in its current form is no better than the kind of advice >> that can be found on Google. >> >> Joe >> > > -- > Mark Nottingham https://www.mnot.net/ > > > > >
Received on Saturday, 5 March 2016 01:06:21 UTC