[TelstraClear] Internet usage when modem is off!!

Forums › One NZ (including Farmside) › [TelstraClear] Internet usage when modem is off!!

1 | ... | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15

176 posts

Master Geek
+1 received by user: 11

#524307 21-Sep-2011 21:55

Beccara: What would you guys do if someone on a big fat connection UDP flooded 50gb of traffic to each of your cable IP ranges? Every single cable user calling you and complaining that their usage is thru the roof and having to hand our credits.?

That attack would be too broad. They'd block it and possibly involve the police. Best to get a throw-away VPS somewhere overseas, pay for with a Prezzy card purchased with cash. (Coz once this kind of stuff starts happening, it starts getting into fraud & unauthorised access type territory.)

Then, only attack a small group of users at a time. And then only the ones that respond to a ping during the day, and then only overnight (don't actually want to seriously DoS someone's connection!)

Perhaps 50 users a month. Even then, I think it could be pretty dodgy. You'd have more luck convincing those users to set up Asterisk boxes with silly passwords (but not actually connected to any paid service!)

Beccara

1473 posts

Uber Geek
+1 received by user: 517

ID Verified

#524313 21-Sep-2011 22:03

freitasm:
DonGould: So, in short what you are saying is that you meter based on traffic thrown at the IP address. So even if the modem is off, any traffic thrown at the IP address is counted by the ERX. Is this correct?

I gave my time and loyalty to your company, yet today I feel fobbed off. I clearly don't trust in your systems and I feel lied to and miss-lead on many levels.

I don't understand why the surprise. This seems to be the norm in the industry. Not only ISPs but hosting providers will charge users by the traffic directed at their IP, regardless if there's a box at the end of the pipe receiving those bits.

It's not a surprise to most but it is a fault with no ppp based connections which unless i'm forgetting things the vast majority of users in this country use. Hostings a whole different kettle of fish but I suspect if you asked the average user if they expected to be billed for traffic when their power was off/modem unplugged/phone line cut the majority of them would say no

Most problems are the result of previous solutions...

All comment's I make are my own personal opinion and do not in any way, shape or form reflect the views of current or former employers unless specifically stated

jnawk

176 posts

Master Geek
+1 received by user: 11

#524314 21-Sep-2011 22:03

freitasm:
DonGould:?So, in short what you are saying is that you meter based on traffic thrown at the IP address.? So even if the modem is off, any traffic thrown at the IP address is counted by the ERX.? Is this correct?

I gave my time and loyalty to your company, yet today I feel fobbed off.? I clearly don't trust in your systems and I feel lied to and miss-lead on many levels.

I don't understand why the surprise. This seems to be the norm in the industry. Not only ISPs but hosting providers will charge users by the traffic directed at their IP, regardless if there's a box at the end of the pipe receiving those bits.

?

I don't know that Don is surprised. Just because it might be the "norm" doesn't make it right.

Telecom has used confusion as a marketing tool

They know we're not being straight up

DOESN'T MAKE IT RIGHT!

jnawk

176 posts

Master Geek
+1 received by user: 11

#524318 21-Sep-2011 22:05

DonGould:I think it's a reasonable consumer expectation that when the modem is off it doesn't use your data cap.

PenultimateHop

637 posts

Ultimate Geek
+1 received by user: 2

Trusted

#524357 22-Sep-2011 00:04

jnawk: That doesn't sit well with me - feel free to point out where I've lost the plot.

Any connection hammering out the traffic will likely be sending maximally sized packets. The packet count to byte count ratio will be tiny.

Hardware exists for extracting the first X many bytes from packets - that is generally how core gear works.

If only the first 40 bytes were read, you would be reading about 3% of the packet, or to put it another way, a 1GBit link could communicate the relevant data for (at most) 330GBit of packets.

I think you'll be statistically more likely to find larger packets than smaller ones, especially in the home user space.

Valid points! However, let me point out:

1. Any RE <> LC bus is not dedicated to Netflow collection, and is used for other traffic as well
2. The bus isn't necessarily GE (plenty of systems use slower busses, e.g. FE or even less), and in some cases while it might be GE at the RE side it isn't GE on the LC side (have a look at the Cisco GSR for an instance of low-speed RE<>LC busses).
3. Many RE CPUs simply aren't capable of dealing with high volumes of traffic as they're not forwarding engines, and they're already very busy dealing with subscriber session state, logging, routing protocols, MPLS adjacencies, and so on. Even if you could forward 1G of fully sampled data from the LCs to the RE you would probably kill the RE in having to deal with it
4. On non-flow switching platforms, the header sampling is done elsewhere in the forwarding process, not necessarily at the ingress FPGA (which only cares about the 2-5 tuple, depending on where some forwarding decisions are made like ECMP). This sampling process needs to extract the full flow data, especially if it is a sprayed flow, and cache it. It then needs to punt it to the RE to be sent to your collector. Many flow collection systems will run afoul of the caching and forwarding requirements well below line-speed, which is why on high end forwarding platforms you typically see 1/1000 sampling. Sometimes as low as 1/250 but it's still sampling.

There's a bunch of other reasons that Netflow is performance-wise annoying too, but it's important to understand that it's really not intended as a billing mechanism these days...

And yes -- I agree, it's unusual in this case that billing is not related to the IP session...

codyc1515

1598 posts

Uber Geek
Inactive user

#524359 22-Sep-2011 00:06

Would you expect your car to keep using Petrol even when it was turned off? I think not.

Quic Broadband

Move to New Zealand's best fibre broadband service (affiliate link). Free setup code: R587125ERQ6VE. Note that to use Quic Broadband you must be comfortable with configuring your own router.

Athlonite

1828 posts

Uber Geek
+1 received by user: 210
Inactive user

#524370 22-Sep-2011 02:19

Gary the use of this analogy is rather daft

"That?s why I used the analogy of the postie delivering the mail whether you?re home or not."

turning off my modem is tantamount to me going outside and ripping out my letter box ie: No letter box No mail wanted or otherwise even if I am at home the postie cannot deliver the mail

you can't say your system doesn't know exactly when and for how long a modem in not connected and so any data received by your system during those times that your system say the modem was off should not be billed to the end user

jnawk

176 posts

Master Geek
+1 received by user: 11

#524383 22-Sep-2011 07:34

PenultimateHop:
jnawk: That doesn't sit well with me - feel free to point out where I've lost the plot.

Any connection hammering out the traffic will likely be sending maximally sized packets. The packet count to byte count ratio will be tiny.

Hardware exists for extracting the first X many bytes from packets - that is generally how core gear works.

If only the first 40 bytes were read, you would be reading about 3% of the packet, or to put it another way, a 1GBit link could communicate the relevant data for (at most) 330GBit of packets.

I think you'll be statistically more likely to find larger packets than smaller ones, especially in the home user space.

Valid points! However, let me point out:

1. Any RE LC bus is not dedicated to Netflow collection, and is used for other traffic as well
2. The bus isn't necessarily GE (plenty of systems use slower busses, e.g. FE or even less), and in some cases while it might be GE at the RE side it isn't GE on the LC side (have a look at the Cisco GSR for an instance of low-speed RELC busses).
3. Many RE CPUs simply aren't capable of dealing with high volumes of traffic as they're not forwarding engines, and they're already very busy dealing with subscriber session state, logging, routing protocols, MPLS adjacencies, and so on. Even if you could forward 1G of fully sampled data from the LCs to the RE you would probably kill the RE in having to deal with it
4. On non-flow switching platforms, the header sampling is done elsewhere in the forwarding process, not necessarily at the ingress FPGA (which only cares about the 2-5 tuple, depending on where some forwarding decisions are made like ECMP). This sampling process needs to extract the full flow data, especially if it is a sprayed flow, and cache it. It then needs to punt it to the RE to be sent to your collector. Many flow collection systems will run afoul of the caching and forwarding requirements well below line-speed, which is why on high end forwarding platforms you typically see 1/1000 sampling. Sometimes as low as 1/250 but it's still sampling.

There's a bunch of other reasons that Netflow is performance-wise annoying too, but it's important to understand that it's really not intended as a billing mechanism these days...

And yes -- I agree, it's unusual in this case that billing is not related to the IP session...

So the nuts and bolts of it is that most hardware isn't designed for billing & ISPs try to shove it on their cheap 'n' nasty hardware rather than pony up serious cash for hardware that is supposed to and capable of getting accurate data..?

jnawk

176 posts

Master Geek
+1 received by user: 11

#524385 22-Sep-2011 07:36

Athlonite: you can't say your system doesn't know exactly when and for how long a modem in not connected and so any data received by your system during those times that your system say the modem was off should not be billed to the end user

It looks like its a "la la la la la la la la la can't hear you la la la la la la" type approach..

PenultimateHop

637 posts

Ultimate Geek
+1 received by user: 2

Trusted

#524387 22-Sep-2011 07:50

jnawk: So the nuts and bolts of it is that most hardware isn't designed for billing & ISPs try to shove it on their cheap 'n' nasty hardware rather than pony up serious cash for hardware that is supposed to and capable of getting accurate data..?

I'm not sure I'd summarize it in quite that manner. There is plenty of hardware, and platforms, that are suitable for generating accurate billing data*. I don't know whether ISPs are failing to implement or failing to purchase.

* There's always going to be some level of unreliability: for instance of a BRAS/BNG crashes (or loses power), you're most likely going to lose some billing data, regardless of the mechanism...

PenultimateHop

637 posts

Ultimate Geek
+1 received by user: 2

Trusted

#524388 22-Sep-2011 07:53

freitasm: I don't understand why the surprise. This seems to be the norm in the industry. Not only ISPs but hosting providers will charge users by the traffic directed at their IP, regardless if there's a box at the end of the pipe receiving those bits.

I'm surprised by this and I'm... somewhat familiar with broadband network architecture. It isn't typical for any session based (IPoE or PPP) architectures to bill when the end-user is disconnected/offline (e.g. RG is offline or cable modem is unplugged - or both).

Hosting is slightly different since it is not session based.

Lego

Shop now for Lego sets and other gifts (affiliate link).

graemeh

2080 posts

Uber Geek
+1 received by user: 226

#524407 22-Sep-2011 08:39

PenultimateHop:
freitasm: I don't understand why the surprise. This seems to be the norm in the industry. Not only ISPs but hosting providers will charge users by the traffic directed at their IP, regardless if there's a box at the end of the pipe receiving those bits.

I'm surprised by this and I'm... somewhat familiar with broadband network architecture. It isn't typical for any session based (IPoE or PPP) architectures to bill when the end-user is disconnected/offline (e.g. RG is offline or cable modem is unplugged - or both).

Hosting is slightly different since it is not session based.

I didn't think the cable network was session based. The cable modem is just a bridge. Unfortunately the network architecture is not suited to the business model of usage based billing as when routing the traffic you don't know if the customer end is on or off.

ADSL is much better suited to usage based billing as the customer equipment sets up an active session when it is connected.

DonGould

3892 posts

Uber Geek
+1 received by user: 164

#524408 22-Sep-2011 08:40

PenultimateHop:
1. Any RE <> LC bus is not dedicated to Netflow collection, and is used for other traffic as well
2. The bus isn't necessarily GE (plenty of systems use slower busses, e.g. FE or even less), and in some cases while it might be GE at the RE side it isn't GE on the LC side (have a look at the Cisco GSR for an instance of low-speed RE<>LC busses).
3. Many RE CPUs simply aren't capable of dealing with high volumes of traffic as they're not forwarding engines, and they're already very busy dealing with subscriber session state, logging, routing protocols, MPLS adjacencies, and so on. Even if you could forward 1G of fully sampled data from the LCs to the RE you would probably kill the RE in having to deal with it
4. On non-flow switching platforms, the header sampling is done elsewhere in the forwarding process, not necessarily at the ingress FPGA (which only cares about the 2-5 tuple, depending on where some forwarding decisions are made like ECMP). This sampling process needs to extract the full flow data, especially if it is a sprayed flow, and cache it. It then needs to punt it to the RE to be sent to your collector. Many flow collection systems will run afoul of the caching and forwarding requirements well below line-speed, which is why on high end forwarding platforms you typically see 1/1000 sampling. Sometimes as low as 1/250 but it's still sampling.

Ok 11 terms there that I can only guess what they are, and others not in the click would have no idea about...

So if you have a second, as we've had over 6,000 views on this thread in such a short time, would you might just expanding those terms to something that people can Google the meaning of?

With respect to the section I underlined, can you please either link an explanation or further explain what sampling means in this instance?

How is it done?

Does it, for example, just check every 1000th packet header and just assume all the others are the same size and from the same locations?

If you're running your flows at 1/1000th, what is the value of that data at all? Why would you even bother to collect it at that resolution? What would it tell you? What would you be looking for?

There's a bunch of other reasons that Netflow is performance-wise annoying too, but it's important to understand that it's really not intended as a billing mechanism these days...

Ok, cool, your view and yet many providers do use this technology in their billing, so how do you suggest they should be doing it?

Promote New Zealand - Get yourself a .kiwi.nz domain name!!!

Check out mine - i.am.a.can.do.kiwi.nz - don@i.am.a.can.do.kiwi.nz

TelstraClear

566 posts

Ultimate Geek
+1 received by user: 2

Trusted

TelstraClear

#524519 22-Sep-2011 11:31

Hi everyone. If you're having specific issues and you want us to look into them, please get in touch.

If you have read my posts you will know how our counting of traffic works, and how the traffic counter feeds into the online usage meter.

You will also know that our traffic counting is accurate, and that the online usage meter is accurate up to the date/time stamp shown on the online meter.

You will know that the online meter isn’t (as is clearly stated) real-time but that it is usually only two hours or less behind. On occasion, the online usage meter can fail to talk to the traffic counter and update the data. This will be obvious because the date/time stamp will be fairly old and it will show you have used no traffic, even if you know you have been online.

The online usage meter was accurate even when we had an issue at the end of July when the traffic counter failed to talk to the online meter. When the online usage meter did update, after a couple of days, the usage that was shown was actual usage. At the time, we acknowledged this problem and apologised for the inconvenience it may have caused. Even though we were under no obligation to do so, we credited some customers whose monthly data was due to reset during that time, and who went over their cap because they had not realised that the meter was not showing the data they were consuming.

If you’ve read my posts, you will also know that we are working on improving the online usage meter so that the updates are, where possible, more frequent, allowing the usage shown to appear closer to the time it was actually used.

You will be aware that we count traffic that is sent from and to your IP address, and that turning your modem off won’t stop traffic that you’ve requested (whether consciously or not) being counted.

We protect you by operating sophisticated security systems that detect and deflect denial of service and other attacks. We cannot tell what traffic you have requested, nor what traffic is being sent to your IP address simply as a consequence of your online behaviour (eg, web sites you have visited, software and content you have downloaded). Your online behaviour may affect the traffic that you, consciously or otherwise, consume.

TelstraClear provides customers with a service that allows them to access the Internet. We do not monitor our customer’s activity on the Internet and we do not inspect the data they are sending or receiving. Our Internet terms and conditions are available online: http://www.telstraclear.co.nz/company-info/terms-and-conditions/internet-services.cfm

We appreciate that customers have a choice of providers, and we’re happy to assist people with specific issues or who would like more information on the services available, or on the products or services that they currently purchase.

We won’t be entering into debates about how we operate. If you do have a specific problem, please let me know and I’ll do what I can to get it sorted for you.

Cheers, Gary

DonGould

3892 posts

Uber Geek
+1 received by user: 164

#524534 22-Sep-2011 11:51

TelstraClear: We won’t be entering into debates about how we operate. If you do have a specific problem, please let me know and I’ll do what I can to get it sorted for you.

Does this mean you now won't be answering the direct questions I asked above?

D

Promote New Zealand - Get yourself a .kiwi.nz domain name!!!

Check out mine - i.am.a.can.do.kiwi.nz - don@i.am.a.can.do.kiwi.nz

1 | ... | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15