Re: Traffic Control Incubation Proposal.

[Jan van Doorn]

I updated the proposal to request git-wip and JIRA.

Thanks,
JvD

On Tue, Jun 21, 2016 at 3:05 PM, Leif Hedstrom  wrote:

>
> > On Jun 17, 2016, at 4:58 PM, John D. Ament 
> wrote:
> >
> > Leif,
> >
> > I doubt this is something IPMC can help you with.  As champion, I would
> > recommend that you reach out to infra to see the appetite to support
> > git-dual on a podling.  You will want to explain the scenario with the
> > "partner” project
>
>
> We discussed this with Infra, and the answer is that this podling would
> need to move to Apache Git servers (git-wip).
>
> Jan: Can you update your proposal accordingly please? Specify the
> resources you wish to use, including Jira or Bugzilla if you so choose. You
> could use the Github issues associated with the Github mirror of the
> podling, but that makes it more difficult to manage I think, since you
> would not be able to do things such as assigning issues etc.
>
> Cheers,
>
> — leif
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Traffic Control Incubation Proposal.

[Jim Jagielski]

kewl. +1

> On Jun 16, 2016, at 5:26 PM, Jan van Doorn  wrote:
> 
> Hi all,
> 
> I would like to discuss the proposal of a new project to the Incubator. 
> 
> Traffic Control is a CDN control plane that was open sourced in April of 
> 2015. 
> 
> The Proposal is pasted below and can be found on the wiki at: 
> https://wiki.apache.org/incubator/TrafficControlProposal 
> 
> 
> Best Regards,
> Jan van Doorn
> 
> ---
> = Traffic Control Proposal =
> 
> == Abstract ==
> 
> Traffic Control allows you to build a large scale content delivery network 
> using
> open source. 
> 
> == Proposal ==
> 
> The goal of this proposal is to bring the Traffic Control project into the
> Apache Software Foundation.
> 
> == Background ==
> 
> Initially built around Apache Traffic Server as the caching software, Traffic
> Control implements all functions of a modern CDN except the caching software:
> 
> * Traffic Router is a Java Tomcat application that routes clients to the 
> closest
> available cache on the CDN using both HTTP and DNS. By using consistent 
> hashing
> it sends requests for the same content to the same cache in a group of caches
> working together in a location. It takes care of routing clients around hot
> spots and problems in the CDN by using the information from Traffic Monitor 
> with
> regards to state of all the caches.
> 
> * Traffic Monitor is a Java Tomcat application that implements the CDN health
> protocol. Every cache in the CDN is checked using HTTP for vital stats, and
> based on these stats, caches are declared healthy or unhealthy. This 
> information
> is then used by Traffic Router to make its routing decisions.
> 
> * Traffic Ops is a Perl Mojolicious and jQuery UI application for management 
> and
> monitoring of all servers in the CDN. All server and content routing 
> information
> for the CDN is managed through Traffic Ops. It also exposes RESTful API
> endpoints for consumption by tools and other applications.
> 
> * Traffic Stats is a Go application that is used to acquire and store 
> statistics
> about CDNs controlled by Traffic Control. Traffic Stats mines metrics from 
> Traffic Monitor’s JSON APIs and stores the data in InfluxDB, and visualizes 
> them 
> using Grafana.
> 
> * Traffic Analytics is a new component we are starting to build for log file 
> analysis, based on Apache Kafka, Heka, and Elastic Search.
> 
> 
> Traffic Control was developed by Comcast Cable and released as open source 
> under
> the Apache 2.0 license in April of 2015. Traffic Control is deployed at 
> Comcast
> and other cable operators.
> 
> The Traffic Control project was presented at ApacheCon NA 2016, see 
> http://bit.ly/1UwMzmR for additional background information.
> 
> == Rationale ==
> 
> Even though the traffic on today's CDNs is strictly defined by open standards,
> and there are many open source implementations of caches available, CDNs are
> still proprietary. The current providers of CDN-as-a-product or
> CDN-as-a-service all have their own proprietary implementation of the control
> plane.  The CDN control plane of one vendor can't interoperate with the CDN
> control plane of another, creating a classic vendor-lockin for 
> CDN-as-a-product
> customers. Traffic Control changes that. Emerging standards from IETF (CDNi
> working group) and the Streaming Video Alliance Open Caching working group 
> need
> an open source reference implementation; Traffic Control will strive to be
> that.
> 
> == Initial Goals ==
> 
> Initial goals of transitioning to ASF is to grow and diversify the community,
> and to move to a more open and inclusive development model.
> 
> == Current Status ==
> 
> Traffic Control is functional and deployed at Comcast and other cable 
> operators.
> In the past 12 months 10 major releases have been made.
> 
> === Meritocracy ===
> 
> Initial development was done at Comcast Cable. Since April 2015  it has been
> open source, and a handful outside contributors have been added.
> 
> Our main goal during incubation is to try to create a more diverse group of
> contributors and users.
> 
> === Community ===
> 
> Traffic Control is being used by a number of cable companies and is being
> evaluated by a number of vendors and ISPs. Two vendors have created products
> based on Traffic Control and are active in the community.
> 
> === Core Developers ===
> 
> Most of the core developers of Traffic Control are currently at Comcast. The
> main goal of the incubation is to grow the developer and user group into a
> community beyond Comcast and US cable.
> 
> === Alignment ===
> 
> Traffic Control is closely aligned with Apache Traffic Server (ATS). The only
> supported cache in a Traffic Control CDN at this time is ATS.  One of our
> proposed mentors is a committers to ATS, and our proposed champion the ATS PMC
> chair.
> 
> We don't want to become a sub-project of ATS though, because we believe we
> should 

Re: Traffic Control Incubation Proposal.

[Leif Hedstrom]

> On Jun 21, 2016, at 1:44 PM, Mattmann, Chris A (3980) 
>  wrote:
> 
> Thanks Leif.
> 
> I’m going to go check them out, but I wonder why it was discussed
> on private?


Likely my mistake, I just let it auto-complete the address.

— Leif


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Traffic Control Incubation Proposal.

[Mattmann, Chris A (3980)]

Thanks Leif.

I’m going to go check them out, but I wonder why it was discussed
on private?

Cheers,
Chris

++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattm...@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++
Director, Information Retrieval and Data Science Group (IRDS)
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
WWW: http://irds.usc.edu/
++









On 6/21/16, 1:27 PM, "Leif Hedstrom"  wrote:

>
>> On Jun 21, 2016, at 1:21 PM, Mattmann, Chris A (3980) 
>>  wrote:
>> 
>> Hmm, I missed the convo on infrastructure@.
>> 
>> Do you have a pointer to it?
>
>
>
>It was on infrastructure-private@.
>
>Cheers,
>
>— leif
>
>
>-
>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Traffic Control Incubation Proposal.

[Leif Hedstrom]

> On Jun 21, 2016, at 1:21 PM, Mattmann, Chris A (3980) 
>  wrote:
> 
> Hmm, I missed the convo on infrastructure@.
> 
> Do you have a pointer to it?



It was on infrastructure-private@.

Cheers,

— leif


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Traffic Control Incubation Proposal.

[Mattmann, Chris A (3980)]

Hmm, I missed the convo on infrastructure@.

Do you have a pointer to it?

Thanks,
Chris

++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattm...@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++
Director, Information Retrieval and Data Science Group (IRDS)
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
WWW: http://irds.usc.edu/
++










On 6/21/16, 12:05 PM, "Leif Hedstrom"  wrote:

>
>> On Jun 17, 2016, at 4:58 PM, John D. Ament  wrote:
>> 
>> Leif,
>> 
>> I doubt this is something IPMC can help you with.  As champion, I would
>> recommend that you reach out to infra to see the appetite to support
>> git-dual on a podling.  You will want to explain the scenario with the
>> "partner” project
>
>
>We discussed this with Infra, and the answer is that this podling would need 
>to move to Apache Git servers (git-wip).
>
>Jan: Can you update your proposal accordingly please? Specify the resources 
>you wish to use, including Jira or Bugzilla if you so choose. You could use 
>the Github issues associated with the Github mirror of the podling, but that 
>makes it more difficult to manage I think, since you would not be able to do 
>things such as assigning issues etc.
>
>Cheers,
>
>— leif
>
>
>-
>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
>

Re: Traffic Control Incubation Proposal.

[Leif Hedstrom]

> On Jun 17, 2016, at 4:58 PM, John D. Ament  wrote:
> 
> Leif,
> 
> I doubt this is something IPMC can help you with.  As champion, I would
> recommend that you reach out to infra to see the appetite to support
> git-dual on a podling.  You will want to explain the scenario with the
> "partner” project


We discussed this with Infra, and the answer is that this podling would need to 
move to Apache Git servers (git-wip).

Jan: Can you update your proposal accordingly please? Specify the resources you 
wish to use, including Jira or Bugzilla if you so choose. You could use the 
Github issues associated with the Github mirror of the podling, but that makes 
it more difficult to manage I think, since you would not be able to do things 
such as assigning issues etc.

Cheers,

— leif


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Traffic Control Incubation Proposal.

[Mattmann, Chris A (3980)]

Sure..

++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattm...@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++
Director, Information Retrieval and Data Science Group (IRDS)
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
WWW: http://irds.usc.edu/
++










On 6/17/16, 4:43 PM, "John D. Ament"  wrote:

>I don't blame you, it's going to be a huge gain for the ASF in general.
>Care to join me in a conversation on infra about this?
>On Jun 17, 2016 19:25, "Mattmann, Chris A (3980)" <
>chris.a.mattm...@jpl.nasa.gov> wrote:
>
>> I am not supportive of any further uses of git-dual while my
>> two requests for Nutch and Tika remain in the queue. I’m sorry
>> but not supportive of that.
>>
>> Chris
>>
>> ++
>> Chris Mattmann, Ph.D.
>> Chief Architect
>> Instrument Software and Science Data Systems Section (398)
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 168-519, Mailstop: 168-527
>> Email: chris.a.mattm...@nasa.gov
>> WWW:  http://sunset.usc.edu/~mattmann/
>> ++
>> Director, Information Retrieval and Data Science Group (IRDS)
>> Adjunct Associate Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> WWW: http://irds.usc.edu/
>> ++
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 6/17/16, 3:58 PM, "John D. Ament"  wrote:
>>
>> >Leif,
>> >
>> >I doubt this is something IPMC can help you with.  As champion, I would
>> >recommend that you reach out to infra to see the appetite to support
>> >git-dual on a podling.  You will want to explain the scenario with the
>> >"partner" project
>> >
>> >Either way, from a project proposal standpoint the git.apache.org URL is
>> >the canonical version, just that git-dual supports bi-directional syncing
>> >of the repos.  I would recommend keeping that as the listed version, to
>> >allow the podling to not be impeded in further discussions over listing
>> the
>> >github URL as the canonical resource.
>> >
>> >John
>> >
>> >On Fri, Jun 17, 2016 at 6:47 PM Leif Hedstrom  wrote:
>> >
>> >>
>> >> > On Jun 16, 2016, at 3:29 PM, Mattmann, Chris A (3980) <
>> >> chris.a.mattm...@jpl.nasa.gov> wrote:
>> >> >
>> >> > Sounds cool!
>> >> >
>> >> > Git-dual is not a broad option right now unfortunately so that will
>> need
>> >> to be updated to git-wp.
>> >> >
>> >>
>> >>
>> >> It this a hard rule? Would infra or the incubator PMC be able to make an
>> >> exception for this incubation? Besides the fact that Traffic Control ist
>> >> already fully hosted on Github, it’s sibling project (Traffic Server) is
>> >> already migrated over to MATT and Github. There are definite benefit for
>> >> both projects if we keep them both on the same infrastructure.
>> >>
>> >> Cheers,
>> >>
>> >> — Leif
>> >>
>> >>
>> >> -
>> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> >> For additional commands, e-mail: general-h...@incubator.apache.org
>> >>
>> >>
>>

Re: Traffic Control Incubation Proposal.

[John D. Ament]

I don't blame you, it's going to be a huge gain for the ASF in general.
Care to join me in a conversation on infra about this?
On Jun 17, 2016 19:25, "Mattmann, Chris A (3980)" <
chris.a.mattm...@jpl.nasa.gov> wrote:

> I am not supportive of any further uses of git-dual while my
> two requests for Nutch and Tika remain in the queue. I’m sorry
> but not supportive of that.
>
> Chris
>
> ++
> Chris Mattmann, Ph.D.
> Chief Architect
> Instrument Software and Science Data Systems Section (398)
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 168-519, Mailstop: 168-527
> Email: chris.a.mattm...@nasa.gov
> WWW:  http://sunset.usc.edu/~mattmann/
> ++
> Director, Information Retrieval and Data Science Group (IRDS)
> Adjunct Associate Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> WWW: http://irds.usc.edu/
> ++
>
>
>
>
>
>
>
>
>
>
> On 6/17/16, 3:58 PM, "John D. Ament"  wrote:
>
> >Leif,
> >
> >I doubt this is something IPMC can help you with.  As champion, I would
> >recommend that you reach out to infra to see the appetite to support
> >git-dual on a podling.  You will want to explain the scenario with the
> >"partner" project
> >
> >Either way, from a project proposal standpoint the git.apache.org URL is
> >the canonical version, just that git-dual supports bi-directional syncing
> >of the repos.  I would recommend keeping that as the listed version, to
> >allow the podling to not be impeded in further discussions over listing
> the
> >github URL as the canonical resource.
> >
> >John
> >
> >On Fri, Jun 17, 2016 at 6:47 PM Leif Hedstrom  wrote:
> >
> >>
> >> > On Jun 16, 2016, at 3:29 PM, Mattmann, Chris A (3980) <
> >> chris.a.mattm...@jpl.nasa.gov> wrote:
> >> >
> >> > Sounds cool!
> >> >
> >> > Git-dual is not a broad option right now unfortunately so that will
> need
> >> to be updated to git-wp.
> >> >
> >>
> >>
> >> It this a hard rule? Would infra or the incubator PMC be able to make an
> >> exception for this incubation? Besides the fact that Traffic Control ist
> >> already fully hosted on Github, it’s sibling project (Traffic Server) is
> >> already migrated over to MATT and Github. There are definite benefit for
> >> both projects if we keep them both on the same infrastructure.
> >>
> >> Cheers,
> >>
> >> — Leif
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
>

Re: Traffic Control Incubation Proposal.

[Mattmann, Chris A (3980)]

I am not supportive of any further uses of git-dual while my
two requests for Nutch and Tika remain in the queue. I’m sorry
but not supportive of that.

Chris

++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattm...@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++
Director, Information Retrieval and Data Science Group (IRDS)
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
WWW: http://irds.usc.edu/
++










On 6/17/16, 3:58 PM, "John D. Ament"  wrote:

>Leif,
>
>I doubt this is something IPMC can help you with.  As champion, I would
>recommend that you reach out to infra to see the appetite to support
>git-dual on a podling.  You will want to explain the scenario with the
>"partner" project
>
>Either way, from a project proposal standpoint the git.apache.org URL is
>the canonical version, just that git-dual supports bi-directional syncing
>of the repos.  I would recommend keeping that as the listed version, to
>allow the podling to not be impeded in further discussions over listing the
>github URL as the canonical resource.
>
>John
>
>On Fri, Jun 17, 2016 at 6:47 PM Leif Hedstrom  wrote:
>
>>
>> > On Jun 16, 2016, at 3:29 PM, Mattmann, Chris A (3980) <
>> chris.a.mattm...@jpl.nasa.gov> wrote:
>> >
>> > Sounds cool!
>> >
>> > Git-dual is not a broad option right now unfortunately so that will need
>> to be updated to git-wp.
>> >
>>
>>
>> It this a hard rule? Would infra or the incubator PMC be able to make an
>> exception for this incubation? Besides the fact that Traffic Control ist
>> already fully hosted on Github, it’s sibling project (Traffic Server) is
>> already migrated over to MATT and Github. There are definite benefit for
>> both projects if we keep them both on the same infrastructure.
>>
>> Cheers,
>>
>> — Leif
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

Re: Traffic Control Incubation Proposal.

[John D. Ament]

Leif,

I doubt this is something IPMC can help you with.  As champion, I would
recommend that you reach out to infra to see the appetite to support
git-dual on a podling.  You will want to explain the scenario with the
"partner" project

Either way, from a project proposal standpoint the git.apache.org URL is
the canonical version, just that git-dual supports bi-directional syncing
of the repos.  I would recommend keeping that as the listed version, to
allow the podling to not be impeded in further discussions over listing the
github URL as the canonical resource.

John

On Fri, Jun 17, 2016 at 6:47 PM Leif Hedstrom  wrote:

>
> > On Jun 16, 2016, at 3:29 PM, Mattmann, Chris A (3980) <
> chris.a.mattm...@jpl.nasa.gov> wrote:
> >
> > Sounds cool!
> >
> > Git-dual is not a broad option right now unfortunately so that will need
> to be updated to git-wp.
> >
>
>
> It this a hard rule? Would infra or the incubator PMC be able to make an
> exception for this incubation? Besides the fact that Traffic Control ist
> already fully hosted on Github, it’s sibling project (Traffic Server) is
> already migrated over to MATT and Github. There are definite benefit for
> both projects if we keep them both on the same infrastructure.
>
> Cheers,
>
> — Leif
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Traffic Control Incubation Proposal.

[Leif Hedstrom]

> On Jun 16, 2016, at 3:29 PM, Mattmann, Chris A (3980) 
>  wrote:
> 
> Sounds cool!
> 
> Git-dual is not a broad option right now unfortunately so that will need to 
> be updated to git-wp.
> 


It this a hard rule? Would infra or the incubator PMC be able to make an 
exception for this incubation? Besides the fact that Traffic Control ist 
already fully hosted on Github, it’s sibling project (Traffic Server) is 
already migrated over to MATT and Github. There are definite benefit for both 
projects if we keep them both on the same infrastructure.

Cheers,

— Leif


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Traffic Control Incubation Proposal.

[Mattmann, Chris A (3980)]

Sounds cool!

Git-dual is not a broad option right now unfortunately so that will need to be 
updated to git-wp.

Sent from my iPhone

> On Jun 16, 2016, at 2:26 PM, Jan van Doorn  wrote:
> 
> Hi all,
> 
> I would like to discuss the proposal of a new project to the Incubator. 
> 
> Traffic Control is a CDN control plane that was open sourced in April of 
> 2015. 
> 
> The Proposal is pasted below and can be found on the wiki at: 
> https://wiki.apache.org/incubator/TrafficControlProposal 
> 
> 
> Best Regards,
> Jan van Doorn
> 
> ---
> = Traffic Control Proposal =
> 
> == Abstract ==
> 
> Traffic Control allows you to build a large scale content delivery network 
> using
> open source. 
> 
> == Proposal ==
> 
> The goal of this proposal is to bring the Traffic Control project into the
> Apache Software Foundation.
> 
> == Background ==
> 
> Initially built around Apache Traffic Server as the caching software, Traffic
> Control implements all functions of a modern CDN except the caching software:
> 
> * Traffic Router is a Java Tomcat application that routes clients to the 
> closest
> available cache on the CDN using both HTTP and DNS. By using consistent 
> hashing
> it sends requests for the same content to the same cache in a group of caches
> working together in a location. It takes care of routing clients around hot
> spots and problems in the CDN by using the information from Traffic Monitor 
> with
> regards to state of all the caches.
> 
> * Traffic Monitor is a Java Tomcat application that implements the CDN health
> protocol. Every cache in the CDN is checked using HTTP for vital stats, and
> based on these stats, caches are declared healthy or unhealthy. This 
> information
> is then used by Traffic Router to make its routing decisions.
> 
> * Traffic Ops is a Perl Mojolicious and jQuery UI application for management 
> and
> monitoring of all servers in the CDN. All server and content routing 
> information
> for the CDN is managed through Traffic Ops. It also exposes RESTful API
> endpoints for consumption by tools and other applications.
> 
> * Traffic Stats is a Go application that is used to acquire and store 
> statistics
> about CDNs controlled by Traffic Control. Traffic Stats mines metrics from 
> Traffic Monitor’s JSON APIs and stores the data in InfluxDB, and visualizes 
> them 
> using Grafana.
> 
> * Traffic Analytics is a new component we are starting to build for log file 
> analysis, based on Apache Kafka, Heka, and Elastic Search.
> 
> 
> Traffic Control was developed by Comcast Cable and released as open source 
> under
> the Apache 2.0 license in April of 2015. Traffic Control is deployed at 
> Comcast
> and other cable operators.
> 
> The Traffic Control project was presented at ApacheCon NA 2016, see 
> http://bit.ly/1UwMzmR for additional background information.
> 
> == Rationale ==
> 
> Even though the traffic on today's CDNs is strictly defined by open standards,
> and there are many open source implementations of caches available, CDNs are
> still proprietary. The current providers of CDN-as-a-product or
> CDN-as-a-service all have their own proprietary implementation of the control
> plane.  The CDN control plane of one vendor can't interoperate with the CDN
> control plane of another, creating a classic vendor-lockin for 
> CDN-as-a-product
> customers. Traffic Control changes that. Emerging standards from IETF (CDNi
> working group) and the Streaming Video Alliance Open Caching working group 
> need
> an open source reference implementation; Traffic Control will strive to be
> that.
> 
> == Initial Goals ==
> 
> Initial goals of transitioning to ASF is to grow and diversify the community,
> and to move to a more open and inclusive development model.
> 
> == Current Status ==
> 
> Traffic Control is functional and deployed at Comcast and other cable 
> operators.
> In the past 12 months 10 major releases have been made.
> 
> === Meritocracy ===
> 
> Initial development was done at Comcast Cable. Since April 2015  it has been
> open source, and a handful outside contributors have been added.
> 
> Our main goal during incubation is to try to create a more diverse group of
> contributors and users.
> 
> === Community ===
> 
> Traffic Control is being used by a number of cable companies and is being
> evaluated by a number of vendors and ISPs. Two vendors have created products
> based on Traffic Control and are active in the community.
> 
> === Core Developers ===
> 
> Most of the core developers of Traffic Control are currently at Comcast. The
> main goal of the incubation is to grow the developer and user group into a
> community beyond Comcast and US cable.
> 
> === Alignment ===
> 
> Traffic Control is closely aligned with Apache Traffic Server (ATS). The only
> supported cache in a Traffic Control CDN at this time is ATS.  One of our
> proposed mentors is a committers to ATS, and our 

Traffic Control Incubation Proposal.

[Jan van Doorn]

Hi all,

I would like to discuss the proposal of a new project to the Incubator. 

Traffic Control is a CDN control plane that was open sourced in April of 2015. 

The Proposal is pasted below and can be found on the wiki at: 
https://wiki.apache.org/incubator/TrafficControlProposal 


Best Regards,
Jan van Doorn

---
= Traffic Control Proposal =

== Abstract ==

Traffic Control allows you to build a large scale content delivery network using
open source. 

== Proposal ==

The goal of this proposal is to bring the Traffic Control project into the
Apache Software Foundation.

== Background ==

Initially built around Apache Traffic Server as the caching software, Traffic
Control implements all functions of a modern CDN except the caching software:

 * Traffic Router is a Java Tomcat application that routes clients to the 
closest
 available cache on the CDN using both HTTP and DNS. By using consistent hashing
 it sends requests for the same content to the same cache in a group of caches
 working together in a location. It takes care of routing clients around hot
 spots and problems in the CDN by using the information from Traffic Monitor 
with
 regards to state of all the caches.

 * Traffic Monitor is a Java Tomcat application that implements the CDN health
 protocol. Every cache in the CDN is checked using HTTP for vital stats, and
 based on these stats, caches are declared healthy or unhealthy. This 
information
 is then used by Traffic Router to make its routing decisions.

 * Traffic Ops is a Perl Mojolicious and jQuery UI application for management 
and
 monitoring of all servers in the CDN. All server and content routing 
information
 for the CDN is managed through Traffic Ops. It also exposes RESTful API
 endpoints for consumption by tools and other applications.

 * Traffic Stats is a Go application that is used to acquire and store 
statistics
 about CDNs controlled by Traffic Control. Traffic Stats mines metrics from 
 Traffic Monitor’s JSON APIs and stores the data in InfluxDB, and visualizes 
them 
 using Grafana.

 * Traffic Analytics is a new component we are starting to build for log file 
 analysis, based on Apache Kafka, Heka, and Elastic Search.


Traffic Control was developed by Comcast Cable and released as open source under
the Apache 2.0 license in April of 2015. Traffic Control is deployed at Comcast
and other cable operators.

The Traffic Control project was presented at ApacheCon NA 2016, see 
http://bit.ly/1UwMzmR for additional background information.

== Rationale ==

Even though the traffic on today's CDNs is strictly defined by open standards,
and there are many open source implementations of caches available, CDNs are
still proprietary. The current providers of CDN-as-a-product or
CDN-as-a-service all have their own proprietary implementation of the control
plane.  The CDN control plane of one vendor can't interoperate with the CDN
control plane of another, creating a classic vendor-lockin for CDN-as-a-product
customers. Traffic Control changes that. Emerging standards from IETF (CDNi
working group) and the Streaming Video Alliance Open Caching working group need
an open source reference implementation; Traffic Control will strive to be
that.

== Initial Goals ==

Initial goals of transitioning to ASF is to grow and diversify the community,
and to move to a more open and inclusive development model.

== Current Status ==

Traffic Control is functional and deployed at Comcast and other cable operators.
In the past 12 months 10 major releases have been made.

=== Meritocracy ===

Initial development was done at Comcast Cable. Since April 2015  it has been
open source, and a handful outside contributors have been added.

Our main goal during incubation is to try to create a more diverse group of
contributors and users.

=== Community ===

Traffic Control is being used by a number of cable companies and is being
evaluated by a number of vendors and ISPs. Two vendors have created products
based on Traffic Control and are active in the community.

=== Core Developers ===

Most of the core developers of Traffic Control are currently at Comcast. The
main goal of the incubation is to grow the developer and user group into a
community beyond Comcast and US cable.

=== Alignment ===

Traffic Control is closely aligned with Apache Traffic Server (ATS). The only
supported cache in a Traffic Control CDN at this time is ATS.  One of our
proposed mentors is a committers to ATS, and our proposed champion the ATS PMC
chair.

We don't want to become a sub-project of ATS though, because we believe we
should add other caching proxies as they are deemed to be a valuable addition to
the Traffic Control CDN.

== Known Risks ==

=== Orphaned products ===

Traffic Control is a new system that does not have wide adoption, but at least
two major North American ISPs are committed to the continued development. Two 
vendors have used it to build