Talk:Virtual circuit

Comment

Hi,

to my knowledge TCP is NO "virtual circuit protocol". A virtual circuit ist virtual as there is np real circuit between the endsystems. X.25, Frame relay and ATM are VC networks. A VC is characterized by the fact that a permanent circuit is built in the connection process. This includes finding the route between the endsystems, and each router on the path allocates a bandwidth for the circuit, i.e. the routers between are holding state information for the circuit!

For reference I quote "Computer Networking: A top down approach featuring the Internet " by Kurose.

Christian

---

There must be a misunderstanding in this article.

I quite agree with Christians opinion here, by my knowledge the "Virtual Circuit" is the states theese switchs are holding, and it will never change while the circuit is in use, as opposed to TCP which is a Datagram network which may choose different paths at each package.

Ivan

TCP is a connection-oriented packet mode protocol, which to my understanding is synonymous to virtual circuit switched. It is carried by a connectionless datagram protocol the IP protocol, but that is another story... . Mange01 09:13, 28 June 2007 (UTC)

I have now completely rewritten the article, in view to further clarify the above. Mange01 19:35, 30 June 2007 (UTC)

The first paragraph is badly mixed up, and badly wrong. A virtual circuit has nothing whatsoever to do with the protocol being a packet, a byte-stream, or a bit-stream oriented protocol. Virtual circuits exist in all 3 types of protocol. "A virtual circuit protocol hides the division into segments, packets or frames from higher level protocols." is completely wrong. TCP is a connection-oriented byte-stream protocol, not a connection-oriented packet mode protocol. TCP is also a Virtual Circuit protocol, but the two are not synonymous. 81.187.162.109 20:18, 21 July 2007 (UTC)

PVC, ADSL modem

No mention here of PVC as it applies to ADSL (except the reference to QOS). Since most (?) ADSL modems have the capacity to set up PVC's for QOS or other reasons, and typically come with no explanation, a brief description of meaning of the acronyms, PVC,VPI,VCI,UBR,CBR,VBR,PCR,SCR,MBS,CDVT, relevant standards, and common values would be useful. —Preceding unsigned comment added by 150.101.166.15 (talk) 08:09, 4 June 2008 (UTC)

TCP does NOT provide a virtual circuit

A circuit is a fixed path over the network from the sender to the receiver host, in TCP packets can take different paths over the network to reach the receiver. —Preceding unsigned comment added by Ppazos (talk • contribs) 15:23, 6 July 2009 (UTC)

Hopefully, I've resolved this by making it more clear that the sequence infomation and reordering allow a TCP connection to be treated as though it's a virtual circuit connection, etc. However, it might still want something on the retries making delay and jitter an even bigger sod to predict than it already is for a virtual circiut.

Graham.Fountain | Talk 13:30, 19 July 2014 (UTC)

Organization

I do not like the organization of the article as it currently stands. TelecomNut ^(talk) 17:14, 13 July 2010 (UTC) I have some suggestions I'd like comment on:

1. I believe (but can not cite) that the virtual circuit concept originated with a way of trying to provide a functionality similar to 64k voice circuits (DS0/E0/J0). I think we'd agree that this is a layer 1 concept. I think that we should order the article from Layer 2 up to Layer X (X <= 7) virtual circuits because they become more virtual the further you get from Layer 1.
2. The Permanent and Switched Virtual Circuits section should fall under Layer 2.
3. Examples should be placed within the various layers.
4. Really well known examples should be placed in the current "Examples" section, which maybe should go first after the header.

TelecomNut ^(talk) 17:14, 13 July 2010 (UTC)

Bullet points in lead.

Looking at the bullet points, it's not clear enough where the first and third are different, as in the variations in queuing delay, at least at the outputs of switches, etc., are caused by varying load from other users sharing the same network resources, e.g. output queue delays are caused primarily by multiplexing at the associated output. Even in the end systems, you can view (and model) variable queuing delays as being caused by multiplexing (if you've a mind to). Anyone any sugestions?

Graham.Fountain | Talk 13:13, 19 July 2014 (UTC)

Proposed merge of Virtual call capability into Virtual circuit

Create a section on the Virtual circuit article to cover Virtual call capability (propose simple merge) Whizz40 (talk) 13:00, 17 February 2020 (UTC)

• Support ~Kvng (talk) 14:34, 20 February 2020 (UTC)
  • Done Whizz40 (talk) 07:01, 12 May 2020 (UTC)

Datagram

The last sentence in the lead says, "An alternate network configuration to virtual circuit is datagram."

I don't have access to this reference but this seems like an apple-oranges comparison and isn't much help to readers. An obvious alternative is connectionless communication. ~Kvng (talk) 17:58, 8 November 2020 (UTC)

Good point. Someone fixed it :) ★NealMcB★ (talk) 18:37, 21 February 2022 (UTC)

References