NTAC Peering Working Group

["David Crowe, Jr." <>]

hi grover,

On 05/24/2013 10:22 AM, Grover Browning wrote:
> Indeed, this gets to the real issues: what's commodity and what's R&E? If a 
> genomics guy stores his sequencer data on AWS is that commodity because it's Amazon 
> or research because he's doing research? And when the bursar at the same site uses 
> AWS is it commodity or R&E?
>
> I suspect the answer is different at each site due to the different policies 
> the membership wants to, or must, follow.

this last point is the main policy issue i was getting at.  we need to 
support both options; we'll have additional ones in the future since 
some services may be better delivered as a direct AL2S connection.

many/most of us make specific choices on our ends with valid business 
and organizational rationale; they just aren't the same choice in the 
collective set.  the I2 infrastructure needs to give us the ability to 
influence traffic to align with that choice.

David


> On May 24, 2013, at 12:52 PM, Ryan Harden 
> <>
>  wrote:
>
> > I've viewed TR-CPS, perhaps incorrectly, as a commodity path via Internet2 and prefer 
> > it only slightly above traditional commodity/ISP paths and slightly below R&E 
> > paths like Internet2 R&E.
> >
> > The question for me is whether we view this new session as a research 
> > endpoint that also happens to serve commodity, or a commodity endpoint that 
> > also happens to serve research.
> > The amount of bandwidth used by the session is irrelevant. If we view it 
> > commodity, home it to TR-CPS, and subsequently it takes up all available 
> > bandwidth, we should add capacity to TR-CPS. The same would be true for Internet2 
> > R&E if we consider it a research endpoint.
> >
> > I honestly don't have much of an opinion either way. I'm not hearing much locally 
> > about the desire to use it for research, but that doesn't mean it isn't happening 
> > or that other's aren't. I just don't want to call it commodity but stick it on 
> > the R&E side to avoid adding capacity to TR-CPS.
> >
> > /Ryan
> >
> > Ryan Harden
> > Senior Network Engineer
> > University of Chicago - AS160
> > P: 773-834-5441
> >
> >
> >
> >
> > On May 24, 2013, at 11:13 AM, "David Crowe, Jr." 
> > <>
> >  wrote:
> >
> > > hi michael,
> > >
> > > On 05/24/2013 08:55 AM, Michael H Lambert wrote:
> > > > On 24 May 2013, at 11:25, Michael H Lambert wrote:
> > > >
> > > > > Speaking pragmatically, I think I'm more concerned about congesting the TR-CPS 
> > > > > links than removing too much headroom on the R&E links.  I won't argue that 
> > > > > this view is *right*.
> > > >
> > > > Replying to my own mail (sorry!)...
> > > >
> > > > If there is a strong consensus that this view is flat-out wrong, then maybe 
> > > > we as a community need to re-evaluate and re-justify the existence of TR-CPS. 
> > > >  Perhaps we need to look at peering strictly on the local and regional 
> > > > levels, even though that would mean more collective effort and the loss of 
> > > > economy of scale.
> > >
> > > in our community i think it has been shown time and time again that the 
> > > collective choices of the connectors land with *both* (and probably more) 
> > > views so they need to be accommodated.
> > >
> > > that point notwithstanding, one big issue that will come to the fore if Net+ 
> > > services are added to the TR-CPS side is the lack of overhead capacity available 
> > > there.  the capacity made available to TR-CPS, both for customer attachment and 
> > > intra-TR-CPS connections, is more frugally managed than on the R&E side; 
> > > there is an explicit intent to control costs but it is also due to very slow 
> > > allocation of resources.
> > >
> > > since the available overhead capacity is much less generous than we've required 
> > > on the R&E side adding more demand on the TR-CPS side will require adding 
> > > more capacity to match or exceed current planning.
> > >
> > > David