Simple 3-way handshake and boom, datastream.
Actually, that isn't quite true.
After the TCP handshake, Telnet will negotiate options related to the session (see the command structure defined in RFC 854). These are done with high byte values (240 through 255) and control things like local echo. If the service you are talking to doesn't correctly ignore these sequences, then they can corrupt the data stream.
netcat is generally a better choice for connecting to generic services that use ASCII command sets.
I think absolutely, ISP's should be allowed to provide faster bandwidth for sites where companies have agreed to pay for delivering content to the consumer at faster transfer rates.
Without adding additional resources (which cost a lot of money), this can only be done by slowing down other traffic. Although blocking is unlikely, slowing down other traffic can make these services unusable, without actually "blocking" that traffic (think 1 frame per second YouTube). This will force the other services to also pay for the fast lane but only the largest sites will be able to afford this.
Say goodbye to new innovative services, especially those that compete with the business models of existing media conglomerates. Free or low-cost services like Skype, Facetime, etc. whose business models depend on equitable sharing of bandwidth will no longer be able to survive in their current form (think monthly fees, no free version). Anything not blessed by the big guys won't have a chance. An example of a big guy in the US: the new Comcast after the upcoming merger.
Yes, it is possible that an ISP could add new resources ($$$) so that the other traffic is not slowed, but think of the business case. In my example, the only cost is some DPI to classify the traffic and you get much more revenue by charging everyone who can afford it more money.
Lower cost + higher revenue + control = BINGO!
I have a very small mind and must live with it. -- E. Dijkstra