This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.
3
2

I read this statement from a supposed Cisco employee on LinkedIn this morning:

"I don't know how many times I've had to say this but there is NO NEGOTIATION in tcp window sizes. In fact, there is NO NEGOTIATION in tcp period. The closest parameter that might come to tcp negotiation is the SACK option at the beginning of the connection."

I often find myself in arguments of semantics..I've found that most people in professions dealing with this level of detail do also. My knee jerk reaction was to post this reply:

"Stating that "there is NO NEGOTIATION in tcp period" is, at best, an argument of semantics. MSS is negotiated, the three-way handshake is, itself, a negotiation, someone mentioned SACK, and what about Window Scaling?"

Someone else in the thread agreed with the Cisco fellow, and I've seen no follow up comments yet.

So I'm asking this community - are there negotiations in TCP? Or are there only notifications of state?

This question is marked "community wiki".

asked 04 Jun '11, 08:54

GeonJay's gravatar image

GeonJay
4705922
accept rate: 5%


I don't think you're going to get a definitive answer here, or anywhere else, because it's very much a matter of semantics. Any response is going to be a matter of opinion, and it depends on exactly where you split the hair. I tend to come down on the side of those who say that there is no negotiation, only announcements of state. To me, "negotiation" means that the two sides have to agree on something, and negotiation is the process by which one or both sides proposes one or more values for a parameter, and then an agreed upon value is selected.

So, MSS is definitely not negotiated. Each system announces its MSS, and the other system abides by it. When computer A sends a SYN packet with an MSS of 1,460 and computer B responds with a SYN/ACK that has an MSS of 1,380, computer A is not "proposing" that they use 1,460, and computer B is not countering with a different proposal; they are simply each announcing their own limit. B will not send any packets with a segment larger than 1,460 bytes to A, and A will not send any packets with a segment larger than 1,380 bytes to B. (There is no requirement that B send 1,460 byte segments to A; only that B not EXCEED 1,460 bytes. B can limit itself to 1,380 bytes if it chooses.)

Compare this with the CIFS Protocol Dialect Negotiation. The client sends a list of the CIFS dialects that it supports; the server compares the list with the dialects that the server supports, and then it selects a common dialect to be used by both the client and server and notifies the client of its selection. That seems to me to be a classic example of negotiation. It results in the use of a common value that both sides agree upon.

How about window scaling? Well, here we get deep into the semantic pit. I would say that each side that supports window scaling announces that fact. But this is English, not binary, and there isn't always precise agreement on definitions, so if you want to describe it by saying that they negotiate the use of window scaling, I'm not going to quibble with your terminology.

However, whether or not window scaling is used, there is no negotiation of the actual window size values. Each side simply announces its window size (and scaling factor, if window scaling is used) and the other side abides by it.

Same for TCP timestamps and selective ACK. Whether you want to say that the two systems "announce" their support for timestamps and/or SACK, or they "negotiate" the use of timestamps and/or SACK is a matter of semantics upon which reasonable people can disagree. However, it is clear that when either timestamps or SACK is used, there is no negotiation of the values. Each side announces its value(s) and the other side accepts it.

Between the two sides of a TCP connection, there is no agreement--negotiated or otherwise--between initial sequence numbers, maximum segment size, timestamp values, window sizes, and selective ACK values. Each side's values are independent of the other's.

Whether you take the position that there is or isn't negotiation in TCP depends on your definition of "negotiation," and we're in a gray area where either definition is defensible. I'm a proponent of precise language in technical areas, but in this case to insist that there is or isn't negotiation in TCP is overly pedantic. The important thing is that we understand and agree about what is happening; not that we agree on whether it can be characterized as "negotiation."

So, while I wouldn't do so, if you want to say that the three-way handshake is a negotiation, have at it. (Although, of course, you're wrong; and BTW, exactly 3,417 angels can fit on the head of a pin. :<) )

permanent link

answered 04 Jun '11, 14:09

Jim%20Aragon's gravatar image

Jim Aragon
7.2k733118
accept rate: 24%

1

Excellent response Jim!!! I have a history of pedantic arguments of semantics. I also have an aversion to absolutes. The language used by that particular submitter struck me as potentially confusing and misleading to folks who are less experienced.

(04 Jun '11, 20:26) GeonJay

Absolutism's are never my favorite, I don't think there is anything absolute in this universe :-)

However, in protocol analysis, it is good to practice to use precise wording to enhance your own understanding and that of others.

If someone thinks of the sending of TCP MSS options as a negotiation, he will think that when A announced a MSS to B of 1460 (as seen at host B) and B announced a MSS of 1380 back to B, it is faulty for B to send a packet with 1460 bytes of TCP payload to A, while in fact it is perfectly OK.

Most exchanges of information in TCP tend to be announcements and not negotiations. However, there are indeed some negotiations. Although things can get a bit misty. Window scaling is a nice hybrid example of a misty situation.

Sending window scaling options can be seen both as a negotiation and as an announcement. The WS option in the SYN packet is the start of the negotiation whether to use window scaling or not. At the same time it is the announcement of which scaling factor the client is going to use (if WS is accepted by the server). The WS in the SYN/ACK is part two of the negotiation telling the client that the server agrees on using window scaling and it is also the announcement of the scaling factor that the server is going to use in its window size announcements.

All in all, I think it all boils down to getting to know the workings of the protocols and trying to use the right wording in each case. It also means helping others understand the little intricacies of a protocol when they do not choose the right wording (I think Guy Harris is a hero in this respect!). The Cisco guy did not get this IMHO (even though I understand that it can become tiresome to explain over and over again to customers how MSS is not a negotiation for example).

permanent link

answered 05 Jun '11, 03:38

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

edited 05 Jun '11, 22:24

I've considered MSS to be negotiated because of my observations and NOT because I actually did my homework and reviewed the process. Usually when Side B announces a smaller MSS, I will also see him adhere to it when he sends large packets. I ASSumed this was required..but it's not. I've thought about it and unless Side B is hardcoded to use a smaller MTU then it's likely that the small MSS was actually set by some network device in the middle of the stream and NOT by SideB itself. Thanks for making me think SYNbit!

(06 Jun '11, 07:38) GeonJay

I said above that I tend to come down on the side of those who say that there are announcements of state, not negotiation, in TCP. After thinking about this some more, and reading Sake's comment, I'm going to move a little more toward the center.

Sticking with my definition of "negotiation" as the process by which two systems agree on something, it's clear that MSS is not negotiated, and initial sequence numbers are not negotiated.

In the case of window scaling, TCP timestamps, and SACK, I think it's fair terminology to say that the USE of these options is negotiated, but the VALUES to be used are announced. (And you can go so far as to consider these announcements to be part of, not separate from, the negotiation process. Have we slogged far enough into the semantic swamp yet?)

So, yes, LinkedIn Cisco guy, there is negotiation in TCP.

permanent link

answered 05 Jun '11, 16:59

Jim%20Aragon's gravatar image

Jim Aragon
7.2k733118
accept rate: 24%

Would calling myself pedantically childish be redundant? ;-) I poked the bear and replied back to the LinkedIn thread..I know that I probably shouldn't have, but I did anyway.

(06 Jun '11, 07:39) GeonJay
1

@GeonJay, I have joined the fray and added my own comment. Again, this is a matter of semantics, which is why I object to Cisco guy's absolute statement.

The real argument here is not over technology, it's over language, which is inherently imprecise.

I don't think anyone disagrees about what happens; the whole argument is about what to call it.

Now go poke the bear some more.

(06 Jun '11, 09:15) Jim Aragon

It is right in the RFC 879 from 1983

This Maximum Segment Size (MSS) announcement (often mistakenly called a negotiation)...

For that part...

permanent link

answered 23 Feb '14, 05:57

TRNCFRMCN's gravatar image

TRNCFRMCN
161
accept rate: 0%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×752
×2
×1

question asked: 04 Jun '11, 08:54

question was seen: 32,691 times

last updated: 23 Feb '14, 05:57

p​o​w​e​r​e​d by O​S​Q​A