[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ippm] Testing TCP Throughput Capacity in Operator Networks



Bonjour Ruediger,

If I may, I would like to comment on the feedback you received from
within your company.

Here in North America, over the last 30 years, we have seen the
monopolistic carriers evolve to competitive Service Providers and even
Application Service Providers. 

There are still pure Carrier Transport SONET type equipments involved in
their core network, but most of the business customer services are now
delivered via an MPLS infrastructure using IP routers and multi-layer
switches in the core, distribution and access layers of the network.

There are also Professional Services groups and Network Security groups
within the organizations involved in business services delivery for some
major customers.

I am pretty sure, that most European PT&Ts have done the same. 

So I do not see why you still make differences between application or
service providers and carriers!

Thanks,
Gilles Forget, CCNP.

On Tue, 2009-10-13 at 11:47 +0200, Ruediger.Geib at telekom.de wrote:
> Hello Barry,
>  
> I'm not sure, whether IPPM is chartered to specify transport layer
> performance metrics. I've checked the PMOL charter and it clearly says
> PMOL works above transport layer. A fair conclusion would be, that
> IPPM is chartered to investigate transport layer performance.
>  
> Three questions to the chairs and to the IPPM WG come to my mind:
>  
> Chairs: Is IPPM chartered to execute the work proposed by Barry?
>  
> IPPM WG: If not, is there interest to charter IPPM for such an
> activity?
>  
> Chairs: If not, to which WG can Barry submit his proposal?
>  
> My personal interest in this activity is limited, saying no support,
> no objection. The feedback I received from within the company I work
> for is, that such an activity is relevant for application or service
> providers, but not for carriers. 
>  
> Regards,
>  
> Ruediger
>  
> Deutsche Telekom Netzproduktion GmbH
> Zentrum Technik Einführung
> Technik Internet Backbone, TE142-19
> Rüdiger Geib
> Heinrich Hertz Str. 3-7
> 64297 Darmstadt
> Tel.: 06151/6282747
> Fax: 0251/7985109
> 
> 
> Deutsche Telekom Netzproduktion GmbH
> Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)
> Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert
> Matheis, Klaus Peren
> Handelsregister: Amtsgericht Bonn HRB 14190
> Sitz der Gesellschaft: Bonn
> USt-IdNr.: DE 814645262
> 
> 
> 
> 
> 
> ______________________________________________________________________
> From: ippm-bounces at ietf.org [mailto:ippm-bounces at ietf.org] On Behalf
> Of Barry Constantine
> Sent: Wednesday, October 07, 2009 12:06 AM
> To: ippm at ietf.org
> Subject: [ippm] Testing TCP Throughput Capacity in Operator Networks
> 
> 
> 
> Hello,
> 
>  
> 
> I work in the communications test industry and we have seen a growing
> need to verify the capacity of a network in terms of end-end TCP
> throughput.  
> 
>  
> 
> Most network operators use RFC-2544 based Layer 3 tests to verify the
> SLA of the network, but this has significant shortcomings since it
> does not verify the ability of the network to carry a customer’s TCP
> traffic.  Ideally, a TCP layer throughput test would detect issues
> with prioritization, queuing, policing, etc.  This type of test could
> also detect issues such as TCP Tail drop phenomena in the network.
> 
> 
> 
> I have spoken to several network operators and equipment providers and
> there is a consistent desire to test throughput at the stateful TCP
> layer, at line rate speeds (1G-10G), and to conduct these tests in a
> standardized manner.
> 
>  
> 
> At a very high level, a standardized TCP layer throughput test would:
> 
>  
> 
> -        Run a latency test and automatically compute the ideal TCP
> window size for the test network
> 
> -        Conduct a series of single and multiple connection TCP tests
> and vary the window size to verify throughput per window size
> 
> -        Conduct QoS testing, tagging the TCP connections with
> appropriate prioritization (DSCP, etc.) and test in the midst of
> background traffic loads
> 
>  
> 
> This is a very simplified description of the test workflow.
> 
>  
> 
> I would like to solicit the interest of members within the IPPM
> workgroup and would like to move forward with a draft document to
> describe this test in detail.
> 
>  
> 
> Thank you,
> 
> Barry
> 
>  
> 
> Principal Member of Technical Staff
> 
>  
> 
> JDSU Communication Test (formerly Acterna)
> 
> Emerging Markets and Technology Research         
> 
> One Milestone Center Court                              
> 
> Germantown, MD 20876                                         
> 
> (W) 240-404-2227                                                
> 
> (C) 301-325-7069
> 
>  
> 
> 
> _______________________________________________
> ippm mailing list
> ippm at ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
-- 
Gilles Forget, CCNP
T : 450.473.5718
C : 514.895.8212
@ : gilles.forget at sympatico.ca