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

From: <[email-masked]>
Date: Fri, 13 Aug 2010 11:42:15 +0200

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

---

From: Barry Constantine <[email-masked]>
Date: Fri, 20 Aug 2010 05:23:48 -0700

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: [email-masked] [mailto:[email-masked]] 
Sent: Friday, August 13, 2010 5:42 AM
To: Barry Constantine
Cc: [email-masked]
Subject: draft-ietf-ippm-tcp-throughput-tm

Barry,

Regards,

Ruediger

---

From: <[email-masked]>
Date: Mon, 23 Aug 2010 09:29:49 +0200

Hello Barry, 

> 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.

That's useful. The concern I expressed is about provider 
external testing on high speed interfaces only.

I've heard of boxes promising to measure Y.1731 performance to 
compliance with SLAs. If I got that right, a vendor suggested 
to fill any spare capacity by dummy traffic just to make 
sure the contractually agreed throughput is available all 
the time.
While that is within SLA and to some extent technically feasible, 
it is not desireable. That's why I'd like to have some hints at 
the right place in the TCP TM draft helping to avoid not really 
useful scenarios.

[snip]

Regards, Ruediger

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

Barry,

Regards,

Ruediger