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

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



Hi Gilles,

the company I work for is rather big and we differentiate between 
branches providing products/services and those which provide transport. 

I agree that one can't completely separate both (you probably are 
aware that European regulation strongly favours a complete separation
of transport and service).

TCP performance is relevant for products. To my department that means, 
if a product manager is interested, he may push standardisation of a 
TCP throughput measurement system. Currently, I'm not aware of any 
demand (but as I said, it's a big company). Different products and 
services may have different typical TCP communication patterns (like 
different RTTs). All different products are served across the same 
backbone. I doubt that product specific backbone engineering makes 
economical sense in a competitive environment. Different products may 
however apply differentiated transport quality for their communication.

The company I work for operates an IPPM compliant SLA validation 
system for nearly 10 years. Several service/product validation systems 
are operated in parallel. I can't recall that there ever has been a 
discussion whether to disable a backbone SLA validation system because 
there is a service validation system working in parallel. They serve 
different purposes, even if they partially measure similar metrics 
or along shared network sections.

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



-----Original Message-----
From: Gilles Forget [mailto:gilles.forget at sympatico.ca] 
Sent: Tuesday, October 13, 2009 5:24 PM
To: Geib, Rüdiger
Cc: ippm at ietf.org
Subject: 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