Talk:Bufferbloat

This is the talk page for discussing improvements to the Bufferbloat article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Archives: 1: 365 days

Computing: Networking Low‑importance

	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).

Internet Low‑importance

	Internet portal This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet 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.InternetWikipedia:WikiProject InternetTemplate:WikiProject InternetInternet articles
Low	This article has been rated as Low-importance on the project's importance scale.

Reducing the buffer size does _not_ eliminate the problem[edit]

"The problem can be eliminated by simply reducing the buffer size on the network hardware"

That's unfortunately not true, it is not that easy. It is true, that when you have bufferbloat, reducing the buffer size reduces the negative impact, but in practice there is no such thing as the optimal buffer size. The right buffer size always depends on the transmission rate, however usually you have multiple destinations with differing transmission rates, making it rather difficult to find the optimal buffer size. — Preceding unsigned comment added by Tddt (talk • contribs) 15:38, 24 July 2011 (UTC)[reply]

This comment is correct. JimGettys (talk) 18:34, 19 December 2011 (UTC)[reply]

In the worst cases it is that simple. If you have 10 seconds of bufferbloat (I do, at max line rate, for real), then reducing it to 1 second bufferbloat will only make things better. Still bloated, but much better. Marchash (talk) 15:11, 17 June 2012 (UTC)[reply]

I have added the caveats discussed here to the statement. ~Kvng (talk) 03:15, 3 May 2020 (UTC)[reply]

History: RFC 970[edit]

This is not a new problem, RFC 970 On Packet Switches With Infinite Storage http://tools.ietf.org/html/rfc970 describes the issue well.

16:34 EDT 2011-09-14 167.104.7.2 (talk) 20:36, 14 September 2011 (UTC)[reply]

It should be noted that the effective semantics of IPv4 has changed since that RFC was submitted, in a way that (at least formally) invalidates its reasoning: The IP TTL is never decremented by more than one at each router the packet passes, so no matter how long packets are buffered they aren't actually discarded the way it is described there. Does anyone know of a stringent analysis of buffering behavior using hop-count semantics for the TTL field? 192.176.1.95 (talk) 17:01, 10 December 2018 (UTC)[reply]

The term "bufferbloat" was NOT coined by Jim Gettys in 2010 nor was it first detailed in 2009[edit]

I can't find sources to corroborate this, but I first encountered the term back in 2002 or 2003. Technical literature first documents the problem as far back as the 1980s, although the term "bufferbloat" was not yet in use.

I'll grant that Gettys may have been the first person to use the term, but that must have been years before 2010.

CmdrSunshine (talk) 18:39, 1 February 2013 (UTC)[reply]

Sources for this and expanding the article would obviously be welcome. Without those, there is little we can do obviously. Martijn Hoekstra (talk) 20:28, 30 November 2013 (UTC)[reply]

See also[edit]

The article links to Network congestion in the lede (it is piped), so I removed it from the see also per WP:SEE ALSO. What's the reason for including it per this undo [1] ? Widefox; talk 18:20, 11 November 2014 (UTC)[reply]

Hello! Please, let's start by having a look at a quote from the WP:SEEALSO guideline:

As a general rule, the "See also" section should not repeat links that appear in the article's body or its navigation boxes.

Thus, this guideline speaks about links that appear as such in the article body. Of course, the selection of "See also" links is always up to "editorial judgment and common sense" (quoted from the same guideline), and in this case having a link to Network congestion simply seems usable to me. Hope you agree. — Dsimic (talk | contribs) 18:45, 11 November 2014 (UTC)[reply]

I'm aware of the guideline - that's why I put the link in the body instead of the see also.

We pipe links all the time. Nothing new. It does not say (or mean) unpiped links. As you say, judgement and common sense which is why I don't agree and put it in the body and took it out of the see also, which is preferred. I'm not gonna edit war over it though. Other opinions welcome. Widefox; talk 18:53, 11 November 2014 (UTC)[reply]

Well, the guideline says "links that appear", and piping clearly changes the appearance of links – if you agree. :) Of course, I'd like to hear opinions from other editors. — Dsimic (talk | contribs) 19:03, 11 November 2014 (UTC)[reply]

If you're trying to prove the guideline says piped links go in see alsos, it doesn't. As you care so much about it, let's just leave it. This is the second time today you've undone my edits which are quite reasonable. Widefox; talk 23:32, 11 November 2014 (UTC)[reply]

Well, I'm trying to say that an article link may be included in a "See also" section if only its piped versions are used in the article body. Sorry, but which is the second edit you're referring to? By the way, I've even thanked you today for reverting my edit, as you were totally right while doing that. — Dsimic (talk | contribs) 23:46, 11 November 2014 (UTC)[reply]

@Dsimic and Widefox: I also happen to disagree with the strict application of WP:SEEALSO. I think articles covering strongly related concepts bear repeating in the "see also" section even if they're already linked in article body. Except in articles that have too many "see alsos", it might be useful to trim them that way. I also disagree with this for example. -- intgr [talk] 19:52, 24 November 2014 (UTC)[reply]

Hello! I'd agree there, as sometimes it might be actually useful to have one or two closely related links repeated in a "See also" section, even if they're already linked in the article body in their "raw" forms. At the same time, that might also be the case if they're already linked only in an included infobox, especially if it's displayed collapsed by default. Creating some strict rules about such links would be pretty much impossible, but it's all about "editorial judgment and common sense" as the WP:SEEALSO guideline already states. — Dsimic (talk | contribs) 21:51, 24 November 2014 (UTC)[reply]

Generally linked once is in both MOSes WP:OVERLINK and WP:SEEALSO. If there's a reason to not follow that consensus for this, sure. Is there? e.g. this is a clear overlink as it's mentioned several times in the article (and linked). Similarly, Native Command Queuing links in the body back, and not repeated in the see also. Widefox; talk 22:35, 24 November 2014 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just modified one external link on Bufferbloat. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

Added archive https://web.archive.org/web/20040622215331/http://www.cord.edu/faculty/zhang/cs345/assignments/researchPapers/congavoid.pdf to http://www.cord.edu/faculty/zhang/cs345/assignments/researchPapers/congavoid.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 07:45, 27 July 2017 (UTC)[reply]