Talk:Head-of-line blocking

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by Networking task force (assessed as Mid-importance).

TODO[edit]

A diagram may assist the understanding further.

There is a diagram now. It does not help me to understand HOL blocking. I presume we're trying to show that the packet at input 1 destined for output 3 would be subject to HOL blocking. Would be more clear if all inputs had a packet destined for output 4 at HOL --Kvng (talk) 04:55, 2 September 2009 (UTC)[reply]

I think the diagram and/or subtitles are confusing. Widefox (talk) 22:29, 22 February 2012 (UTC)[reply]

Effect on switch throughput[edit]

This phenomenon limits the throughput of switches to 58.6%.

Where did this statistic come from? (Karmastan 22:23, 17 February 2007 (UTC))

The statistic is not true in all contexts either. It's true for packets that are randomly distributed, but that's not always the case.--131.111.236.123 (talk) 16:10, 30 November 2008 (UTC)[reply]

Right, too bad it was stuck here so long. Let us say 56.4% of statistics are meaningless, and 84.3% are random numbers made up on the spot. Seriously, what the paper says is with a certain model of the switch and a specific traffic pattern, then the input buffers saturate at 58.6% of utilization. But other switches and other trafic patterns behave differently. Many even worse, so this is still an issue, but needs to be clarified. Will try to paraphrase what the paper says. W Nowicki (talk) 22:51, 6 May 2011 (UTC)[reply]

HOL in TCP[edit]

I think the article needs to mention a different definition of HOL blocking in the context of TCP. If packet N gets dropped, when N+1, N+2, N+3, ... is received, instead of ACK'ing with N+1, N+2, etc., it ACK's with N-1. This creates an inherent problem in TCP that allows only one hole to be filled each round trip time.

Robertbrichter 13:43, 15 October 2007 (UTC) Robert Richter[reply]

HOL can significantly increase packet reordering...

I think that is the seed of the issue. But I do not have that paper, and its online abstract does not mention HOL. Does it mean the HOL blocking itself causes the re-ordering? Or do its solutions (non FIFO input queues) cause it? I can imagine either, from underlying link aggregation I would assume. Although your statement might be totally accurate, since the SACK option provides for selective acknowledgment in modern stacks, perhaps for this reason. W Nowicki (talk) 18:21, 8 May 2011 (UTC)[reply]

I tried to broaden the definition to cover more than just switches. This needs more work, including a proper definition. Widefox (talk) 22:29, 22 February 2012 (UTC)[reply]

What causes this?[edit]

The article is rather unclear on what the cause or causes of this problem may be. This basic fact should be in the lead. -- Beland (talk) 15:41, 27 August 2014 (UTC)[reply]