"George and Sam exceeded my expectations of simple humans." GODDDD
The 4D GoDDDD will always be greater than the parochial 3D GoDDD, never as shallow as the 2D GoDD, and really the 1D GoD is just a human word/acronym sort of thing meaning Go-Dogma and totally open to local interpretation/spin.
"Dogma affected never reason effective." Oldhawk777
Final words: "Party on and be excellent to one another." George
George was one of the best of US with the "Right Stuff". %~G
The corporatist-welfare state oppresses creativity and innovation by law. The corporatist-welfare state economy provides wealth for few and nothing for US.
The big-brother thought police... close to... almost... damn, it must be there ain't no other way to define this faux-benevolent totalitarian regime corporate-welfare state.
Freedom, Independence, Democracy, Individuality, Capitalism... all dieing in US, EU.... Mao-China/Stalin-Russia/Godly-Clergy have won nothing and we have gained oppression of free-thought.
Capitalism, "Open" (as in FREEDOM) market competition, sound economic policy and laws....
Damn fools, that shit died years ago, get over it and start supporting our New American Ways of "Corporate-Welfare" socialism, Institutional Privatization of Personal Intellectual Property (IP-PIP), Government Bailout Protection (GBP) and Special Tax Incentives (STI) to support amoral Corporatist, Politician, and Clergy executive pay and privileges.
There is a new and better class of US Citizens representing their mantra "Separate, but equal" as the New America promise.
Within any packet-switched network, when demand exceeds available capacity, the packet switch will use a queue to hold the excess packets. When this queue fills, the packet switch must drop packets. Any reliable data protocol that operates across such a network must recognize this possibility and take corrective action. TCP is no exception to this constraint. TCP uses data sequence numbering to identify packets, and explicit acknowledgements (ACKs) to allow the sender and receiver to be aware of reliable packet transfer. This form of reliable protocol design is termed "end-to-end" control, because interior switches do not attempt to correct packet drops. Instead, this function is performed through the TCP protocol exchange between sender and receiver. TCP uses >>>cumulative ACKs rather than per-packet ACKs, where an ACK referencing a particular point within the data stream implicitly acknowledges all data with a sequence value less than the ACKed sequence.
>>> TCP also uses ACKs to clock the data flow. ACKs arriving back at the sender arrive at intervals approximately equal to the intervals at which the data packets arrived at the sender. If TCP uses these ACKs to trigger sending further data packets into the network, then the packets will be entered into the network at the same rate as they are arriving at their destination. This mode of operation is termed "ACK clocking."
>>> TCP recovers from packet loss using two mechanisms. The most basic operation is the use of packet timeouts by the sender. If an ACK for a packet fails to arrive within the timeout value, the sender will retransmit the oldest unacknowledged packet. In such a case, TCP assumes that the loss was caused by a network congestion condition, and the sender will enter "Slow Start" mode. This condition causes significant delays within the data transfer, because the sender will be idle during the timeout interval and upon restarting will recommence with a single packet exchange, gradually recovering the data rate that was active prior to the packet loss. Many networks exhibit transient congestion conditions, where a data stream may experience loss of a single packet within a packet train. To address this, TCP introduced the mechanism of "fast recovery." This mechanism is triggered by a sequence of three duplicate ACKS received by the data sender. These duplicate ACKs are generated by the packets that trail the lost packet, where the sender ACKs each of these packets with the ACK sequence value of the lost packet. In this mode the sender immediately retransmits the lost packet and then halves its sending rate, continuing to send additional data as permitted by the current TCP sending window. In this mode of operation, "congestion-avoidance" TCP increases its sending window at a linear rate of one segment per Round-Trip Time (RTT). This mode of operation is referred to as Additive Increase, Multiplicative Decrease (AIMD), where the protocol reacts sharply to signs of network congestion, and gradually increases its sending rate in order to equilibrate with concurrent TCP sessions.
Now, if you still know you're right, then you're right... I can be wrong for folks when it is in my benefit. Also, thanks... it has been about a decade sense last I looked up some TCP/IP info. I sent my first email in 1984 name5678@IPv4.octet.address.ip (yes, before DNS).
On the issue of ACK... give your comment to the person that initially used the terms in their post (NOT me!). I simply used the same terms for their post not yours. IOW: get a real issue.
TCP applications on local clients/servers can ack/something-worked nak/something-failed with a local mail server all damn day, BFD... I would call that a thrashing/misbehaving/bad (shut it down) TCP application, because it would be as problematic on my network as a thrashing Ethernet card.
There is no need (it is worthless) to confirm each successful packet delivery.
Resend missing/failed/corrupted packets does have value and is required for TCP applications to work properly. If there is a reply-request to confirm successful delivery of all related packets, then an ACK/reply will be sent to the sending TCP application, by the receiving TCP application, confirming complete clean (no errors) reception of all packets associated with the email including all the attachments.
Poor understanding/implementation of TCP/IP appears to be the problem for folks, TCP and IP work very well together on the Internet.
Can we innovate (make things better)...? Always yes, but indicating that a lack of QoS bandwidth is not the root-problem for the Internet in the USA (especially) is pure BS that IAP (CableCo/TelCo) want you and congress/politicians to believe.
Wow, you win, there are AC motors with gears for clocks, washing-machines....
Most folks today when they read/hear the word electronics normally think that some DC/electronics (not electrical) components are involved. I agree, AC motors are electrical and in the USA+ use ~56...63Hz, EU+ use ~47...53Hz, but....
You seriously need to go read. "NACK/ACK (old S&F/RUID terms)" indicates you are clueless about why I used the terms that were in the post I replied too. NACK/ACK are old terms (pre-Internet) used in messaging and other communications software/documentation for store&forward switches and messaging systems that used RUID (Route User/Unique ID [AKA: R community]...), all long before the "Internet". Do you know what BBN, stands for what about SUN... anyway you should read up on many things including TCP/IP.
Anyone can toss bit buckets, a few of us can take the trash and make something... I suspect this AC in only capable of bit-bucket-tossing or VBasic coding.
Consider telecommunications infrastructure "IAP" access (CableCo/TelCo) providers different from the "ISP" content/services (Google, Yahoo, MSN,/., SecondLife, Wired, PBS...) providers. VoIP is an ISP service that can be problematic when the IAP decides to reduced QoS bandwidth between points A&B.
IOW: Access ain't Service, services/content (ISP) cannot be delivered without infrastructure access (IAP)... if the IAP access QoS/bandwidth is shit, then the ISP will deliver services/content shit to their customers.
Invest in QoS bandwidth not bullshit excuses for problems, either the IAP can deliver what you need for business and home or (if possible, there may be only one choice in your region/area) you need to find (or pray, typical in USA homes and small-biz) for another IAP.
NACK/ACK (old S&F/RUID terms) is not an IP responsibility. ACK/NACK for TCP packet delivery failure is only noticeable at the destination client/server computer.... The IP part is the only part used by the IAP (CableCo/TelCo) infrastructure there is no consideration of the content TCP packets, failure to deliver, and/or the order/time of delivery. The TCP origin of an email/file does not need any ACK-confirmation that a packet was received at the intended destination, but the TCP origin does require a NACK-notice (to initiate a resend specific packet) when a specific packet was not received or corrupt (no need to resend the whole email/file); So, in some ways it perhaps prevents a great deal of unnecessary Internet traffic.
Non-neutral network that does proper QOS by throttling bandwidth-heavy protocols that don't behave themselves on the network is acceptable.
Stop getting D/DOS attacks and/or badly configured networks confused with TCP/IP. Yes, TCP/IP is an overhead heavy protocol, but there are legitimate reasons, and a lack of QoS bandwidth is always the problem on the Internet for ISP content/services providers and customers.
Quit listening to IT product marketeers (AKA: vendors with and agenda)
ComCast is a cable TV company that supports Net-Nepotism, because they are both an IAP (primary) and ISP (secondary) and ending Net-Neutrality would expand monopoly like powers over the USA Internet by IAPs like ComCast, but not improve QoS bandwidth to urban and rural communities, small-biz, or citizens at home.
Innovation requires investment and reinvestment... the IAPs do not appear to have any great interest in expensive innovation/infrastructure investments that provide QoS bandwidth increases at capitalist "Open"market competitive prices for every one in the USA.
Consider telecommunications infrastructure "IAP" access (CableCo/TelCo) providers different from the "ISP" content/services (Google, Yahoo, MSN,/., SecondLife, Wired, PBS...) providers.
QoS Bandwidth delivered by IAPs, in the past, was found to be very questionable by the QoS Bandwidth ISP customers that wanted to confirm that they (ISPs) were indeed receiving the QoS bandwidth for which they contracted and paid. The typical home/biz user is in the business of trusting their IAP and not verifying QoS and bandwidth, which would be to complicated (for small biz and private users) and cost them too much.
Letting either IAP or ISP control everything will never provide innovations or QoS improvements. We already pay for QoS bandwidth access, and don't need more bullshit about what causes jitter/UDP bullshit. Almost all Internet bandwidth problems are caused by a lack of reinvestment into infrastructure by the IAPs.
I do have some old experience, I see some BS in the phrases he uses.
The Internet's traffic system does not gives preferential treatment to short/fast communication paths unless you are stupid enough to configure your network/telecommunications backbone-architecture to the S/FPF rather then route on QoS metrics and implied content criticality. TCP is ignored by the backbone it is part of the package and cannot route, only the IP part is the destination/route information use for packet-switching, ATM cell-switching is another backbone technology and (yes) both are (can be) used at the biz-office LAN/WAN network level.
The technical term is semantics "round-trip time effect." Critical content delivery requires TCP/IP not time and a protocol like UDP is important for real-time/streaming content VoIP/VTC/.... UDP Packets (no need to manage) dropped/corrupt cannot be recovered, but TCP/IP has a process for packet dropped/corrupt recovery. UDP is a good fast protocol on LANs and for multimedia/broadcast (can case jitter/distortion), but UDP is not appropriate for email/downloads of large/critical files across the internet, because the complete email/file would then require another complete send/download. The less your RTT is not always best for TCP/IP (assured content delivery is critical) traffic, the faster UDP speeds, the more traffic you can deliver is great for VoIP, streaming MP* files....
IOW: Bandwidth and QoS is best kept net-neutral, and CableCo (or whichever IAP) needs to invest in their infrastructure and innovation not screw their customers with bullshit/legislation. Oh, some folks (like me), consider infrastructure "IAP" access (CableCo/TelCo) providers different from the "ISP" content/services (Google, Yahoo, MSN,/., SecondLife, Wired, PBS...) providers. Letting either IAP or ISP control everything is corporate-welfare monopolies or worse, and will never provide innovations or QoS improvements. We already pay for bandwidth access and QoS, and don't need more bullshit about what causes (lack of reinvestment) jitter/UDP bullshit.
VoIP functions best when it receives a stream of uninterrupted packets, but reality is VoIP was meant to function acceptable for voice communications and when there is adequate bandwidth provided VoIP provides an acceptable phone conversation. VoIP (the protocol) does not (as best I know) give a shit about consistent gaps... for the voice conversation it would be nice, but the answer is bandwidth investment and/or truth in advertising (VoIP and get crappy due to limited bandwidth (or mother nature) problems).
File transfer (FTP) applications simply care about the time between the request for the file and the time the last bit is received and if the file is corrupted then you/application make other FTP request for a clean+usable file. In between, it doesn't matter if the packets are timed by a metronome or if they arrive in a specific sequence of clumps when using TFTP. Jitter is the engineering/common term for variations in delay when data is corrupted/unrecoverable causing voice/video/content... distortion.
Asynchronous Transfer Mode (ATM) (Cell switching) does manage both bandwidth and QoS, far better than packet switching and is great for VoIP/VTC....
The Internet is neutral with respect to applications and to location... the content provider/customer is paying for the bandwidth and QoS; So, how/what they use to send and receive content is of no damn business to any Cableco/TelCo/... IAP who are being paid to provide QoS access to bandwidth for the content sharing industry and their home/biz customers.
The internet is not neutral with respect to QoS bandwidth... if you cannot provide, then content/service providers and their customers can use a different IAP... if thee is another IAP in their IAP's access area. Stupid IAP investment and poor i
All electronic products I know of use DC operationally, AC is just for power distribution over distances and throughout the house/biz.
So, yes, presently all electronics (radio/tv... phone/ipod) or their chargers have transformers and/or rectifiers the adjust AC-voltage levels and/or convert AC to DC electricity.
Anyway, home/biz with WCS could buy products in the future that weigh less, are smaller, cheaper, and use have far less wires/plugs in a mess.
Info/NetSec functions fall under CTO or CIO at HQ location.
When I saw CSO, I chuckled, reminds me of legacy viewgraph [powerpoint] engineers... an animated breed of pet-rock. I feel many (not only USA) companies' C?O positions are populated by animated breeds of pet-rock.
So many can screw-up, all their lives, and get very well paid. We all know that worker-bees, pack-mules, liberal-public-heathens, and unexpected (totally surprising) economic conditions are the most believable cause of business failures, and problematic presidential decisions are mostly due to bad weather and other outside forces beyond anyone's control. %~P it is all just so vary funny and very repetitively consistent anti-capitalism corporate-welfare for well connected losers.
Sighting employee's violation of the policy is the real NetSec violation along with any NetSec policy being employee-centric. Security through obscurity is becoming security by scape-goat, both will always be management/CEO/CIO/CTO... "feel-good" perpetual failures with more paper-policy (less NetSec).
You are for more right than Bishop is wrong... or something like that.
THE MISSION IS ALL! Security that prevents mission/CoreBiz+ performance is more harmful than valuable to the mission. However, probable mission success without some respectable and reasonable degree of security can be problematic.
Don't let security stop reality. Keep security in perspective and segment the critical (plans, G2, accounts...) content & systems from the daily office/public traffic. Security policy fails when you rely on people (the general office/public) keeping all the SecBS as ITgods-laws. Pay for a quality IT staff, retain them, keep them trained, outside-audit and stress-test your NetSec (OEM/OSD/OSP products/services updates, methods, edge-test/eval...). Secure your network, systems, servers/services, content... and be ready to share as much as possible or collaboration synergy without letting the evil ones know everything. Security is not a job for fools or dictators.
Best NetSec advice... GetSmartStaySharp and it will always be about Information Management and Sharing IMS with the best possible NetSec invisible to your staff, customers, and public. Never TripUp your users, layer your security, one level never fits all and is never effective from... use PKI, Biometrics, monitoring, forensics....
Must control change (Plutocrats, Clergy, Politicians, Sycophants...) or change will control (Society, Education, Democracy, Destiny, Economics...).
The weakest link is obvious to me; Also, like paedophiles (freak-controllers) need to be kept far-far away from change..., until change is far too mature for the perverts to show any interest.
I recommend providing freak-controllers (Plutocrats, Clergy, Politicians, Sycophants...) free-porn on their computers to distract them (in private, is never what they say in public).
I have my two OLPC, maybe I'll check my email at HOPE, next month, with it. Then Thanksgiving next, I will take them to my sister for all her grandkids to use and learn.
The na-sayers are full of bullshit, but I am tired of debating with the stupid-HSS (that elected HSS bush&chaney twice) the merits of projects like OLPC.
Slashdot Mirror
"Greetings my excellent friends!" Rufus
"George and Sam exceeded my expectations of simple humans." GODDDD
The 4D GoDDDD will always be greater than the parochial 3D GoDDD, never as shallow as the 2D GoDD, and really the 1D GoD is just a human word/acronym sort of thing meaning Go-Dogma and totally open to local interpretation/spin.
"Dogma affected never reason effective." Oldhawk777
Final words: "Party on and be excellent to one another." George
George was one of the best of US with the "Right Stuff". %~G
Sanity by mandate is highly over-rated by US.
The corporatist-welfare state oppresses creativity and innovation by law.
The corporatist-welfare state economy provides wealth for few and nothing for US.
The big-brother thought police ... close to ... almost ... damn, it must be there ain't no other way to define this faux-benevolent totalitarian regime corporate-welfare state.
Freedom, Independence, Democracy, Individuality, Capitalism ... all dieing in US, EU .... Mao-China/Stalin-Russia/Godly-Clergy have won nothing and we have gained oppression of free-thought.
Capitalism, "Open" (as in FREEDOM) market competition, sound economic policy and laws....
Damn fools, that shit died years ago, get over it and start supporting our New American Ways of "Corporate-Welfare" socialism, Institutional Privatization of Personal Intellectual Property (IP-PIP), Government Bailout Protection (GBP) and Special Tax Incentives (STI) to support amoral Corporatist, Politician, and Clergy executive pay and privileges.
There is a new and better class of US Citizens representing their mantra "Separate, but equal" as the New America promise.
That can only be fucking right, obviously.
For all the trolls/marketeers on /. that downgraded or insulted those of us on /. that told you that Broadband in the USA was an advert-lie %~P.
A Review of TCP Performance
Within any packet-switched network, when demand exceeds available capacity, the packet switch will use a queue to hold the excess packets. When this queue fills, the packet switch must drop packets. Any reliable data protocol that operates across such a network must recognize this possibility and take corrective action. TCP is no exception to this constraint. TCP uses data sequence numbering to identify packets, and explicit acknowledgements (ACKs) to allow the sender and receiver to be aware of reliable packet transfer. This form of reliable protocol design is termed "end-to-end" control, because interior switches do not attempt to correct packet drops. Instead, this function is performed through the TCP protocol exchange between sender and receiver. TCP uses >>>cumulative ACKs rather than per-packet ACKs, where an ACK referencing a particular point within the data stream implicitly acknowledges all data with a sequence value less than the ACKed sequence.
>>> TCP also uses ACKs to clock the data flow. ACKs arriving back at the sender arrive at intervals approximately equal to the intervals at which the data packets arrived at the sender. If TCP uses these ACKs to trigger sending further data packets into the network, then the packets will be entered into the network at the same rate as they are arriving at their destination. This mode of operation is termed "ACK clocking."
>>> TCP recovers from packet loss using two mechanisms. The most basic operation is the use of packet timeouts by the sender. If an ACK for a packet fails to arrive within the timeout value, the sender will retransmit the oldest unacknowledged packet. In such a case, TCP assumes that the loss was caused by a network congestion condition, and the sender will enter "Slow Start" mode. This condition causes significant delays within the data transfer, because the sender will be idle during the timeout interval and upon restarting will recommence with a single packet exchange, gradually recovering the data rate that was active prior to the packet loss. Many networks exhibit transient congestion conditions, where a data stream may experience loss of a single packet within a packet train. To address this, TCP introduced the mechanism of "fast recovery." This mechanism is triggered by a sequence of three duplicate ACKS received by the data sender. These duplicate ACKs are generated by the packets that trail the lost packet, where the sender ACKs each of these packets with the ACK sequence value of the lost packet. In this mode the sender immediately retransmits the lost packet and then halves its sending rate, continuing to send additional data as permitted by the current TCP sending window. In this mode of operation, "congestion-avoidance" TCP increases its sending window at a linear rate of one segment per Round-Trip Time (RTT). This mode of operation is referred to as Additive Increase, Multiplicative Decrease (AIMD), where the protocol reacts sharply to signs of network congestion, and gradually increases its sending rate in order to equilibrate with concurrent TCP sessions.
... I can be wrong for folks when it is in my benefit. Also, thanks ... it has been about a decade sense last I looked up some TCP/IP info. I sent my first email in 1984 name5678@IPv4.octet.address.ip (yes, before DNS).
Now, if you still know you're right, then you're right
On the issue of ACK... give your comment to the person that initially used the terms in their post (NOT me!). I simply used the same terms for their post not yours. IOW: get a real issue.
... I would call that a thrashing/misbehaving/bad (shut it down) TCP application, because it would be as problematic on my network as a thrashing Ethernet card.
TCP applications on local clients/servers can ack/something-worked nak/something-failed with a local mail server all damn day, BFD
There is no need (it is worthless) to confirm each successful packet delivery.
Resend missing/failed/corrupted packets does have value and is required for TCP applications to work properly. If there is a reply-request to confirm successful delivery of all related packets, then an ACK/reply will be sent to the sending TCP application, by the receiving TCP application, confirming complete clean (no errors) reception of all packets associated with the email including all the attachments.
Poor understanding/implementation of TCP/IP appears to be the problem for folks, TCP and IP work very well together on the Internet.
Can we innovate (make things better)...? Always yes, but indicating that a lack of QoS bandwidth is not the root-problem for the Internet in the USA (especially) is pure BS that IAP (CableCo/TelCo) want you and congress/politicians to believe.
Wow, you win, there are AC motors with gears for clocks, washing-machines ....
....
Most folks today when they read/hear the word electronics normally think that some DC/electronics (not electrical) components are involved. I agree, AC motors are electrical and in the USA+ use ~56...63Hz, EU+ use ~47...53Hz, but
You seriously need to go read. "NACK/ACK (old S&F/RUID terms)" indicates you are clueless about why I used the terms that were in the post I replied too. NACK/ACK are old terms (pre-Internet) used in messaging and other communications software/documentation for store&forward switches and messaging systems that used RUID (Route User/Unique ID [AKA: R community] ...), all long before the "Internet". Do you know what BBN, stands for what about SUN ... anyway you should read up on many things including TCP/IP.
... I suspect this AC in only capable of bit-bucket-tossing or VBasic coding.
Anyone can toss bit buckets, a few of us can take the trash and make something
Consider telecommunications infrastructure "IAP" access (CableCo/TelCo) providers different from the "ISP" content/services (Google, Yahoo, MSN, /., SecondLife, Wired, PBS ...) providers. VoIP is an ISP service that can be problematic when the IAP decides to reduced QoS bandwidth between points A&B.
... if the IAP access QoS/bandwidth is shit, then the ISP will deliver services/content shit to their customers.
IOW: Access ain't Service, services/content (ISP) cannot be delivered without infrastructure access (IAP)
Invest in QoS bandwidth not bullshit excuses for problems, either the IAP can deliver what you need for business and home or (if possible, there may be only one choice in your region/area) you need to find (or pray, typical in USA homes and small-biz) for another IAP.
NACK/ACK (old S&F/RUID terms) is not an IP responsibility. ACK/NACK for TCP packet delivery failure is only noticeable at the destination client/server computer .... The IP part is the only part used by the IAP (CableCo/TelCo) infrastructure there is no consideration of the content TCP packets, failure to deliver, and/or the order/time of delivery. The TCP origin of an email/file does not need any ACK-confirmation that a packet was received at the intended destination, but the TCP origin does require a NACK-notice (to initiate a resend specific packet) when a specific packet was not received or corrupt (no need to resend the whole email/file); So, in some ways it perhaps prevents a great deal of unnecessary Internet traffic.
Non-neutral network that does proper QOS by throttling bandwidth-heavy protocols that don't behave themselves on the network is acceptable.
Stop getting D/DOS attacks and/or badly configured networks confused with TCP/IP. Yes, TCP/IP is an overhead heavy protocol, but there are legitimate reasons, and a lack of QoS bandwidth is always the problem on the Internet for ISP content/services providers and customers.
Quit listening to IT product marketeers (AKA: vendors with and agenda)
How would you rate ComCast Internet QoS and bandwidth?
ComCast is a cable TV company that supports Net-Nepotism, because they are both an IAP (primary) and ISP (secondary) and ending Net-Neutrality would expand monopoly like powers over the USA Internet by IAPs like ComCast, but not improve QoS bandwidth to urban and rural communities, small-biz, or citizens at home.
... the IAPs do not appear to have any great interest in expensive innovation/infrastructure investments that provide QoS bandwidth increases at capitalist "Open"market competitive prices for every one in the USA.
Innovation requires investment and reinvestment
Consider telecommunications infrastructure "IAP" access (CableCo/TelCo) providers different from the "ISP" content/services (Google, Yahoo, MSN, /., SecondLife, Wired, PBS ...) providers.
QoS Bandwidth delivered by IAPs, in the past, was found to be very questionable by the QoS Bandwidth ISP customers that wanted to confirm that they (ISPs) were indeed receiving the QoS bandwidth for which they contracted and paid. The typical home/biz user is in the business of trusting their IAP and not verifying QoS and bandwidth, which would be to complicated (for small biz and private users) and cost them too much.
Letting either IAP or ISP control everything will never provide innovations or QoS improvements. We already pay for QoS bandwidth access, and don't need more bullshit about what causes jitter/UDP bullshit. Almost all Internet bandwidth problems are caused by a lack of reinvestment into infrastructure by the IAPs.
I do have some old experience, I see some BS in the phrases he uses.
....
/., SecondLife, Wired, PBS ...) providers. Letting either IAP or ISP control everything is corporate-welfare monopolies or worse, and will never provide innovations or QoS improvements. We already pay for bandwidth access and QoS, and don't need more bullshit about what causes (lack of reinvestment) jitter/UDP bullshit.
... for the voice conversation it would be nice, but the answer is bandwidth investment and/or truth in advertising (VoIP and get crappy due to limited bandwidth (or mother nature) problems).
... the content provider/customer is paying for the bandwidth and QoS; So, how/what they use to send and receive content is of no damn business to any Cableco/TelCo/... IAP who are being paid to provide QoS access to bandwidth for the content sharing industry and their home/biz customers.
... if you cannot provide, then content/service providers and their customers can use a different IAP ... if thee is another IAP in their IAP's access area. Stupid IAP investment and poor i
The Internet's traffic system does not gives preferential treatment to short/fast communication paths unless you are stupid enough to configure your network/telecommunications backbone-architecture to the S/FPF rather then route on QoS metrics and implied content criticality. TCP is ignored by the backbone it is part of the package and cannot route, only the IP part is the destination/route information use for packet-switching, ATM cell-switching is another backbone technology and (yes) both are (can be) used at the biz-office LAN/WAN network level.
The technical term is semantics "round-trip time effect." Critical content delivery requires TCP/IP not time and a protocol like UDP is important for real-time/streaming content VoIP/VTC/.... UDP Packets (no need to manage) dropped/corrupt cannot be recovered, but TCP/IP has a process for packet dropped/corrupt recovery. UDP is a good fast protocol on LANs and for multimedia/broadcast (can case jitter/distortion), but UDP is not appropriate for email/downloads of large/critical files across the internet, because the complete email/file would then require another complete send/download. The less your RTT is not always best for TCP/IP (assured content delivery is critical) traffic, the faster UDP speeds, the more traffic you can deliver is great for VoIP, streaming MP* files
IOW: Bandwidth and QoS is best kept net-neutral, and CableCo (or whichever IAP) needs to invest in their infrastructure and innovation not screw their customers with bullshit/legislation. Oh, some folks (like me), consider infrastructure "IAP" access (CableCo/TelCo) providers different from the "ISP" content/services (Google, Yahoo, MSN,
VoIP functions best when it receives a stream of uninterrupted packets, but reality is VoIP was meant to function acceptable for voice communications and when there is adequate bandwidth provided VoIP provides an acceptable phone conversation. VoIP (the protocol) does not (as best I know) give a shit about consistent gaps
File transfer (FTP) applications simply care about the time between the request for the file and the time the last bit is received and if the file is corrupted then you/application make other FTP request for a clean+usable file. In between, it doesn't matter if the packets are timed by a metronome or if they arrive in a specific sequence of clumps when using TFTP. Jitter is the engineering/common term for variations in delay when data is corrupted/unrecoverable causing voice/video/content... distortion.
Asynchronous Transfer Mode (ATM) (Cell switching) does manage both bandwidth and QoS, far better than packet switching and is great for VoIP/VTC....
The Internet is neutral with respect to applications and to location
The internet is not neutral with respect to QoS bandwidth
SomeFYI: NFM (NoFyckingMagic)
... phone/ipod) or their chargers have transformers and/or rectifiers the adjust AC-voltage levels and/or convert AC to DC electricity.
http://gizmodo.com/gadgets/gadgets/wild-charge-hands+on-really-does-charge-wirelessly-227215.php
http://www.crunchgear.com/2007/07/08/wildcharger-charges-wirelessly/
http://videos.howstuffworks.com/university-of-florida/3792-wireless-charging-station-video.htm
All electronic products I know of use DC operationally, AC is just for power distribution over distances and throughout the house/biz.
So, yes, presently all electronics (radio/tv
Anyway, home/biz with WCS could buy products in the future that weigh less, are smaller, cheaper, and use have far less wires/plugs in a mess.
Info/NetSec functions fall under CTO or CIO at HQ location.
... an animated breed of pet-rock. I feel many (not only USA) companies' C?O positions are populated by animated breeds of pet-rock.
When I saw CSO, I chuckled, reminds me of legacy viewgraph [powerpoint] engineers
So many can screw-up, all their lives, and get very well paid. We all know that worker-bees, pack-mules, liberal-public-heathens, and unexpected (totally surprising) economic conditions are the most believable cause of business failures, and problematic presidential decisions are mostly due to bad weather and other outside forces beyond anyone's control. %~P it is all just so vary funny and very repetitively consistent anti-capitalism corporate-welfare for well connected losers.
I second this as another security truth. Whatever happened to PKI, biometrics ... and other technologies to help those poor pitiful techphobic C?Os.
I second this as another security truth.
CSO, good-one, I have noticed that as the number of C*O positions increase the more businesses screw-up, fail, lose money ....
...). CSO is another good funnnnnnny.
Maybe a stock investment rule can be found surveying corporations' C*O positions and quantity (CEO, CIO, CTO, CSO
Sighting employee's violation of the policy is the real NetSec violation along with any NetSec policy being employee-centric. Security through obscurity is becoming security by scape-goat, both will always be management/CEO/CIO/CTO... "feel-good" perpetual failures with more paper-policy (less NetSec).
I second this as truth, because twice I have been the target of pet-rock management blame-storm witch-hunts (I'm still here, I think, maybe not).
I second-second this as truth.
You are for more right than Bishop is wrong ... or something like that.
...) content & systems from the daily office/public traffic. Security policy fails when you rely on people (the general office/public) keeping all the SecBS as ITgods-laws. Pay for a quality IT staff, retain them, keep them trained, outside-audit and stress-test your NetSec (OEM/OSD/OSP products/services updates, methods, edge-test/eval ...). Secure your network, systems, servers/services, content ... and be ready to share as much as possible or collaboration synergy without letting the evil ones know everything. Security is not a job for fools or dictators.
... GetSmartStaySharp and it will always be about Information Management and Sharing IMS with the best possible NetSec invisible to your staff, customers, and public. Never TripUp your users, layer your security, one level never fits all and is never effective from ... use PKI, Biometrics, monitoring, forensics ....
THE MISSION IS ALL! Security that prevents mission/CoreBiz+ performance is more harmful than valuable to the mission. However, probable mission success without some respectable and reasonable degree of security can be problematic.
Don't let security stop reality. Keep security in perspective and segment the critical (plans, G2, accounts
Best NetSec advice
Must control change (Plutocrats, Clergy, Politicians, Sycophants ...) or ...).
..., until change is far too mature for the perverts to show any interest.
...) free-porn on their computers to distract them (in private, is never what they say in public).
change will control (Society, Education, Democracy, Destiny, Economics
The weakest link is obvious to me; Also, like paedophiles (freak-controllers) need to be kept far-far away from change
I recommend providing freak-controllers (Plutocrats, Clergy, Politicians, Sycophants
I have my two OLPC, maybe I'll check my email at HOPE, next month, with it. Then Thanksgiving next, I will take them to my sister for all her grandkids to use and learn.
The na-sayers are full of bullshit, but I am tired of debating with the stupid-HSS (that elected HSS bush&chaney twice) the merits of projects like OLPC.