Is there parallelism in packet-switching?

Question

Let's say there are two hosts h1 and h2 separated by a switch w set up in this manner

[h1]----link1----[w]----link2----[h2]

If we are to send a file divided evenly into two packets from h1to h2 using packet switching, how would this happen? Let's assume that queueing and processing delays are negligible (0), and link1 is twice as long as link2.

My question is that, once packet1 finished transmission from h1 to link1, can it proceed with propagating packet1 to w and transmitting packet2 to link1 at the same time in some sort of parallelism?

Answer 1

First of all, this is a very nice question, so kudos for asking it.

Next:

1. Packets are a very generic term that is not well-defined. I prefer using packet as synonymous to datagram, which is network-layer Protocol Data Unit. In some circles, you could say that a packet is a L3PDU.
2. Since the question is asking about "switching" and is talking about "packets" begin placed on links, I will take the liberty and look at this question only from a Data Link point of view. Thus, I will use the term frame.
3. The link1 that is used here is an Ethernet cable, an optic cable, or a radio wave. In any case, once a bit is placed in the link, there is no way of stopping the bit from flowing, and anyone listening on the link will receive the bit after some time (we call this time propagation delay).

So:

Yes, a host (h1 in the above example), generally, has no restriction as to how quickly it can place L2PDUs (frames) onto a data link. So, in the above example, h1 can place frames onto link1 as fast as its Network Interface Card (NIC) will allow. So let us assume that h1 has a 1Gbps Ethernet NIC. Frame1 is 8 kilobits long, so it should take h1 8 microseconds to put it onto link1 (ignoring L1 synchronization overheads, assuming 1:1 symbol efficiency and assuming a perfect L1 link). h1 is free to place Frame2 onto link1 right after afterwards.

The length of the links only affects the propagation delay and nothing else. So, in this case, if the switch w is pushing frames through to link2 as soon as it realizes where this frame should go, then switch w only needs a shallow memory buffer to store small parts of Frame1 before copying them onto link2. If switch w is actually overwhelmed and its buffers are filled, switch w may request host h1 to slow down. Ethernet allows link-attached devices to slow down other too-fast devices with PAUSE frames.

This is called serial transmission. Each frame is transmitted by h1 onto link1 one after the other. Ethernet is a serial communication media. A NIC can only place a single bit on the Ethernet medium at any given moment. There is no way to transmit two bits (let alone frames) on Ethernet simultaneously. Of popular data link (or physical layer) technologies, only MIMO WiFi supports the transmission of data in parallel, but this whole process breaks down at the data link layer. Even for WiFi, frames appear to be delivered serially.

If you are talking about Transport layer multiplexing, then yes, it may appear that multiple streams of communication happen in parallel between end-hosts (several processes appear to communicate in parallel), but at the data link layer, frames are transmitted in serial.

Answer 2

A switch can send and receive frames on different ports in parallel. It can even do that on the same port when it's in full-duplex mode (which is pretty much the norm today). Modern, fixed-port switches are generally non blocking, their forwarding capacity is only limited by their port number and link speeds.

Parallel receiving and transmitting isn't limited to switches. Most hosts and routers can also do so by using interface hardware that handles transmission and reception autonomously to some extent. The level of that autonomous operation and subsequent parallelism may vary greatly though.

Whether h1 sends the second packet right after the first one depends entirely on the protocols it is using. With a transport-layer protocol like TCP it would send packet after packet containing segmented data until the connection's send window is filled. Each acknowledged segment advances the send window and triggers new segments (extremely simplified), there's a flow of packets.

If the transport-layer protocol can't take care of streaming then the application-layer protocol might - but those are explicitly off topic here.