TCP MSS question

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

TCP MSS question

goldsimon@gmx.de
Two questions about our TCP implementation:

- RFC 1122 says TCP should send with an MSS of "536 if no MSS option is
received" (chapter 4.2.2.6). We send with our configured TCP_MSS
instead. Since even Windows sends with 536 (btw: what does linux do?),
we should maybe change our code to meet the RFC?

- tcp_parseopt() doesn't allow a send MSS (advertised by the remote
side) to be larger than the configured TCP_MSS. Is this included in
order to configure memory usage or does it have other reasons?

Simon


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

Re: TCP MSS question

Jonathan Larmour
[hidden email] wrote:
> Two questions about our TCP implementation:
>
> - RFC 1122 says TCP should send with an MSS of "536 if no MSS option is
> received" (chapter 4.2.2.6). We send with our configured TCP_MSS
> instead. Since even Windows sends with 536 (btw: what does linux do?),
> we should maybe change our code to meet the RFC?

I think the intention of that is to limit it so that it does not exceed
536, rather than be 536 exactly. This is almost certainly because the
standard minimum MTU for the internet is 576. In practice of course, the
MTU is usually more than 576, and the MSS therefore could be more than
536, which is why the temptation would be to send more.

So we could probably change tcp_connect and tcp_alloc to set up the pcb with:
   pcb->mss = (TCP_MSS > 536) ? 536 : TCP_MSS;
and ensure the MSS option we build to send ourselves uses TCP_MSS, not
pcb->mss.

It's true that people may want to configure a larger TCP_MSS in general,
especially when using devices on a LAN that are not routeable on the wider
net, and when they know the environment it's going to be used in (more
likely in the contexts lwIP is used in than Windows/*nix). But we're only
talking about the case when the remote end hasn't sent an MSS option
(which wouldn't even include lwIP for example) so I don't think it's a big
concern.

> - tcp_parseopt() doesn't allow a send MSS (advertised by the remote
> side) to be larger than the configured TCP_MSS. Is this included in
> order to configure memory usage or does it have other reasons?

That was my belief. It certainly seems reasonable that a system with a
small receive MSS is not likely to have enough memory for an unlimited (up
to the MTU) send MSS.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

Re: TCP MSS question

Kieran Mansley
In reply to this post by goldsimon@gmx.de
On Sun, 2007-10-28 at 19:19 +0100, [hidden email] wrote:
> Two questions about our TCP implementation:
>
> - RFC 1122 says TCP should send with an MSS of "536 if no MSS option is
> received" (chapter 4.2.2.6). We send with our configured TCP_MSS
> instead. Since even Windows sends with 536 (btw: what does linux do?),
> we should maybe change our code to meet the RFC?

Yes, I think we should change to use a max of 536 in those cases.  It's
perhaps a bit out dated for local area networks, but can still make
sense when running over longer links.

> - tcp_parseopt() doesn't allow a send MSS (advertised by the remote
> side) to be larger than the configured TCP_MSS. Is this included in
> order to configure memory usage or does it have other reasons?

I'm happier leaving that one as it is, as I suspect it does make
configuring memory usage simpler if we can know in advance what the
upper limit will be on received segments.

Kieran



_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

Re: TCP MSS question

goldsimon@gmx.de
Kieran Mansley schrieb:

> On Sun, 2007-10-28 at 19:19 +0100, [hidden email] wrote:
>  
>> Two questions about our TCP implementation:
>>
>> - RFC 1122 says TCP should send with an MSS of "536 if no MSS option is
>> received" (chapter 4.2.2.6). We send with our configured TCP_MSS
>> instead. Since even Windows sends with 536 (btw: what does linux do?),
>> we should maybe change our code to meet the RFC?
>>    
>
> Yes, I think we should change to use a max of 536 in those cases.  It's
> perhaps a bit out dated for local area networks, but can still make
> sense when running over longer links.
>  
That was exatcly my point of view, too.

>  
>> - tcp_parseopt() doesn't allow a send MSS (advertised by the remote
>> side) to be larger than the configured TCP_MSS. Is this included in
>> order to configure memory usage or does it have other reasons?
>>    
>
> I'm happier leaving that one as it is, as I suspect it does make
> configuring memory usage simpler if we can know in advance what the
> upper limit will be on received segments.
>  
Didn't want to change that, only asking questions :)
And the answer is what I thought, too, so I'm OK with it, of course.

Simon


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel