x
<<   <   Page 6 / 9   >   >>
rtg_dude 12/5/2012 | 12:14:38 AM
re: Caspian Comes Out TheNet:

Let me add context to my statements. What I am suggesting is that "session based real-time data services" (such as VOIP or video etc) will be signaled, "just as" PSTN phone calls are. The call process includes, but not limited to, admission control, resource reservations, policing, traffic management etc.

...

...I am not sure this forum is the right place for doing this.


You are exactly right, it is not. Why don't you write a draft and bring it to the IETF. Just let us know which WG the IESG sends you to, I don't want to miss the fun.

rtg_dude
rtg_dude 12/5/2012 | 12:14:36 AM
re: Caspian Comes Out TheNet-

I do not consider the IETF to be the place of choice for advancing data networking to the next level. I feel the ITU & ETSI are much more credible.
Perfect! I am sure they will like your proposals. Don't forget to post a message here via the world-wide ITUnet using the ETSI protocol stack.

rtg_dude
netskeptic 12/5/2012 | 12:14:36 AM
re: Caspian Comes Out
TheNet - do you care to review a draft I wrote a while ago ?

Thanks,

Netskeptic
TheNet 12/5/2012 | 12:14:35 AM
re: Caspian Comes Out Netskeptic wrote:
"TheNet - do you care to review a draft I wrote a while ago ?"

[TheNet] If you think I can add value, I would be happy to do so. What do you propose as a "meeting" place?
netskeptic 12/5/2012 | 12:14:32 AM
re: Caspian Comes Out

> What do you propose as a "meeting" place?

Send me a e-mail to [email protected]

Thanks,

Netskeptic
TheNet 12/5/2012 | 12:14:31 AM
re: Caspian Comes Out
Netskeptic,

Check for a message from "[email protected]".

[TheNet]
DocGonzo 12/5/2012 | 12:14:12 AM
re: Caspian Comes Out All of this discussion about flows and flying pigs is entertaining. Perhaps these are some of Caspian's finest hours (or 15 minutes.)

Assuming that flow management/forwarding is a good idea and they can deliver, they still have some real world hurdles. Internet users today are hardly tolerant of SP's introducing something disruptive into their online experience. I fail to see how an SP can cost-effectively introduce this technology into their network without any significant disruption. Given the tight windows for network maintenance, it seems a real challenge to have enough time to insert and test this stuff with adequate fallback time. The Catch-22 here seems to be SP's will not deploy something without adequate confidence and SP's can not test it confidently without deploying it.

History has shown that the best approach to entering this market is start with providing baseline competence with the incumbent(s). Some have tried approaches with disruptive technology and proven out the difficulty in that course. Others have tried to just beat out the incumbents and found it hard to survive.

It will be interesting to see how internet routing evolves. Every day that goes by makes it harder to introduce new and disruptive technology due to the potential for outages. The testing required to build adequate confidence prior to deployment is tedious and costly. Considering all of this, I think Caspian will be extremely challenged in the future to get enough pioneers to sign up and deploy their version of the future and sustain the company.

Doc
rjmcmahon 12/5/2012 | 12:14:11 AM
re: Caspian Comes Out So here is my question: how in the heck can a single router in the core implement flow-based routing and have any effect on the QoS of the flow?

If the flow traversed (at least initially) the router, couldn't that have some effect?

Flow QoS is an end-to-end issue, not a per-router issue

Not sure how flow QoS could be realized without router (and forwarder) involvement. Is that possible? (My engineering is rusty -- been spending too much time worrying about politics ;-)

The place where it has the biggest impact (by orders of magnitude) is on a customer's access line, not on core trunks.

Agreed. Maybe we could fix the access lines and get rid of that congestion (and the lobbyist) rather than throwing expensive flow based technology at that problem? (I know Wall St. prefers pick and shovels over public infrastructure, but heck, we all don't live by the rules of Wall St. quite yet.)
arch_1 12/5/2012 | 12:14:11 AM
re: Caspian Comes Out While at ARPA, Larry roberts presided over the birth of APRANET, which was the datagram-based predecessor to the datagram-based Internet. The fundamental concepts of ARPA and IP routing explicitly make "flows" a host function, not a network function.

Larry decided that this was not going to scale and that there was no way for carriers to make money on it, so he then left ARPA and formed Telenet in the mid-1970's to build an SVC-based network and a protocol (X.25) to go with it. Larry is therefore the real father of both IP and X.25.

Here is the important point: X.25 (and its SVC decendents Frame Relay, ATM, and MPLS) are protocols with explicitly-signalled flows. Larry had to build an entire network to implement it in 1976, not just a new router.

So here is my question: how in the heck can a single router in the core implement flow-based routing and have any effect on the QoS of the flow? Flow QoS is an end-to-end issue, not a per-router issue, and the place where it has the biggest impact (by orders of magnitude) is on a customer's access line, not on core trunks.

BobbyMax 12/5/2012 | 12:14:10 AM
re: Caspian Comes Out Caspian wants to launch its products based on reliability based on reliability and scalability. None of these objectives have been by achieved by Caspian. nI sincerely hope no carrier in the US, Europe and Asia believes the claims made by Caspian.
<<   <   Page 6 / 9   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE