Geekzone: technology news, blogs, forums
Guest
Welcome Guest.
You haven't logged in yet. If you don't have an account you can register now.


View this topic in a long page with up to 500 replies per page Create new topic
1 | ... | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15
176 posts

Master Geek
+1 received by user: 11


  Reply # 524307 21-Sep-2011 21:55
Send private message

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!)

975 posts

Ultimate Geek
+1 received by user: 148

UberGroup

  Reply # 524313 21-Sep-2011 22:03
Send private message

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 

 
 
 
 


Try Wrike: fast, easy, and efficient project collaboration software
176 posts

Master Geek
+1 received by user: 11


  Reply # 524314 21-Sep-2011 22:03
Send private message

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!

176 posts

Master Geek
+1 received by user: 11


  Reply # 524318 21-Sep-2011 22:05
Send private message

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


+1

637 posts

Ultimate Geek
+1 received by user: 2

Trusted

  Reply # 524357 22-Sep-2011 00:04
Send private message

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




1598 posts

Uber Geek
Inactive user


  Reply # 524359 22-Sep-2011 00:06
Send private message

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

1828 posts

Uber Geek
+1 received by user: 215
Inactive user


  Reply # 524370 22-Sep-2011 02:19
Send private message

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

176 posts

Master Geek
+1 received by user: 11


  Reply # 524383 22-Sep-2011 07:34
Send private message

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

176 posts

Master Geek
+1 received by user: 11


  Reply # 524385 22-Sep-2011 07:36
Send private message

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

637 posts

Ultimate Geek
+1 received by user: 2

Trusted

  Reply # 524387 22-Sep-2011 07:50
Send private message

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

637 posts

Ultimate Geek
+1 received by user: 2

Trusted

  Reply # 524388 22-Sep-2011 07:53
Send private message

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.

2075 posts

Uber Geek
+1 received by user: 228

Subscriber

  Reply # 524407 22-Sep-2011 08:39
Send private message

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.

3888 posts

Uber Geek
+1 received by user: 163


  Reply # 524408 22-Sep-2011 08:40
Send private message

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


566 posts

Ultimate Geek
+1 received by user: 2

Trusted
TelstraClear

  Reply # 524519 22-Sep-2011 11:31
Send private message

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

3888 posts

Uber Geek
+1 received by user: 163


  Reply # 524534 22-Sep-2011 11:51
Send private message

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 | ... | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15
View this topic in a long page with up to 500 replies per page Create new topic



Twitter »

Follow us to receive Twitter updates when new discussions are posted in our forums:



Follow us to receive Twitter updates when news items and blogs are posted in our frontpage:



Follow us to receive Twitter updates when tech item prices are listed in our price comparison site:





News »

Opera launches new mobile browser: Opera Touch
Posted 25-Apr-2018 20:45


TCF and Telcos Toughen Up on Scam Callers
Posted 23-Apr-2018 09:39


Amazon launches the International Shopping Experience in the Amazon Shopping App
Posted 19-Apr-2018 08:38


Spark New Zealand and TVNZ to bring coverage of Rugby World Cup 2019
Posted 16-Apr-2018 06:55


How Google can seize Microsoft Office crown
Posted 14-Apr-2018 11:08


How back office transformation drives IRD efficiency
Posted 12-Apr-2018 21:15


iPod laws in a smartphone world: will we ever get copyright right?
Posted 12-Apr-2018 21:13


Lightbox service using big data and analytics to learn more about customers
Posted 9-Apr-2018 12:11


111 mobile caller location extended to iOS
Posted 6-Apr-2018 13:50


Huawei announces the HUAWEI P20 series
Posted 29-Mar-2018 11:41


Symantec Internet Security Threat Report shows increased endpoint technology risks
Posted 26-Mar-2018 18:29


Spark switches on long-range IoT network across New Zealand
Posted 26-Mar-2018 18:22


Stuff Pix enters streaming video market
Posted 21-Mar-2018 09:18


Windows no longer Microsoft’s main focus
Posted 13-Mar-2018 07:47


Why phone makers are obsessed with cameras
Posted 11-Mar-2018 12:25



Geekzone Live »

Try automatic live updates from Geekzone directly in your browser, without refreshing the page, with Geekzone Live now.



Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly to your computer or smartphone by using a feed reader.

Alternatively, you can receive a daily email with Geekzone updates.