Re: [ippm] draft-ietf-ippm-tcp-throughput-tm

[Barry Constantine <[e-mail]>]

Hello Reudiger,

Thank you for reviewing the draft again.  This is a good point and item for clarification.

The draft was born with the primary intention of being conducted by network providers as another level of turn-up testing prior to end business customer hand-off.  Also this test could be used as a troubleshooting mechanism by the provider when the end-customer issues complaints concerning performance.

I have personally seen manual TCP testing conducted by network providers for both reasons listed above.  The manual nature of these tests and the network provider technician's inexperience with TCP testing, often leads to variable and non-conclusive results.

Enterprise customers are using tools such as "Iperf", "ttcp", etc. and are running throughput tests to verify the SLA that they purchased from the provider.  The enterprise customer challenges the provider's SLA and in most cases, the provider can only defend the SLA with Layer 2/3 test data.

I believe the majority of use cases will be over Ethernet / IP managed networks and not leased line interface but this will vary.  When I have been involved in these sort of tests (either Layer 2/3 packet stress tests or TCP), the network provider coordinates these tests either before the service is activated or during "off" hours with the end-customer.  And of course, these tests are controlled to be within the SLA purchased by the end customer.  

Thanks,

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

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Friday, August 13, 2010 5:42 AM
To: Barry Constantine
Cc: [e-mail]
Subject: draft-ietf-ippm-tcp-throughput-tm

Barry,

the aspect was mentioned during the Maastricht meeting and by this mail it goes to the list too:

Is tcp-throughput-tm designed to be performed on dedidcated infrastructure (like a leased line infrastructure) only, or is it designed to operate on shared infrastructure (like VRF based L2 or L3 VPNs)? This should be stated explicitely in the text.

If tcp-throughput-tm is designed for shared infrastructure, any test incurring load to a level that congestion in a providers network is a likely outcome should be coordinated with that provider (or not be performed at all). IETF likes to avoid numbering performance, but my personal take is if a customer interface can transmit a load of more than 10% of a single provider edge network internal interface bandwidth, the provider may like to be informed about these load tests. As far as I understand, most business customers hardly congest their own interfaces, meaning that loads of a level of more than 90% of such an interface shouldn't occur. Further, standard traffic has an address entropy enabling load sharing within the providers network. We have experience with a special customer whose traffic didn't meet the above provider expectations while being of high bandwidth. We agreed that the customer informs the NOC when planing to create traffic with the unusual patterns mentioned above.

I think that a company requesting a tcp-throughput-tm from someone may be annoyed if the NOC of the povider gives the companie's network admin a call inquiring what's going on there even before service started.

Should the intention of the draft however be to induce congestion in a provider network, please add a clear statement expressing that.

Regards,

Ruediger