NTAC Peering Working Group

["Hutchins, Ronald R" <>]

SDN will fix this ;-)

On May 24, 2013, at 1:23 PM, 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.
> 
> 
> 
> 
> 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
>