TCP fragmentation

[Turiko]

I am developing a TCP/IP implementation for an embedded system. Whilst everything is at present, fine and dandy, I have a nagging question.

Many embedded coders recommend the stack be able to assemble up to two fragmented TCP datagrams. I see this, as being a bit of a risk.

Now I would like some advice from people who really know TCP well- what is the absolute minimum that one's TCP stack needs to tolerate in terms of fragmented datagrams? I need to know this so that I can ensure I have enough buffer memory for the reassembly of fragmented TCP datagrams.

 

[Turiko]

Anyone that can help? I need to make the necessary decisions as to whether I need to add more RAM or not to the device

 

[Messugga]

Surely this depends largely on the amount of fragmentation? Connection speed should also influence it, if I'm not mistaken. How difficult would it be for you to add more RAM?

 

[Turiko]

The problem is we're working with a processor that has no external bus, and the internal RAM is slowly getting to the end of limit. I am thinking of adding external RAM but it will be slow as I will have to use I/O to get to the RAM.

I am concerned about this because the end product will be used with residential broadband products, where fragmentation is bound to occur, because the MTU is less than 1500... to my mind we will only ever see 2 fragments, but I am not sure I've never studied TCP packet sniffing to this level.

 

[Messugga]

My methodology is "better safe than sorry", but wouldn't it be possible to add a bit of redundancy in order to eliminate the few fragments you'll get?
Care to share what hardware you're using? I could ask some of the design guys if they have an suggestions regarding RAM expansion and how to approach your problem.

 

[HavocXphere]

end product will be used with residential broadband products

I would design it so that there is enough mem/capacity to handle an average of 2.1 fragments per packet. imo 2 is not enough and 3 is overkill.

So the actual code should be able to handle 3+ frags per packet, but the capacity in terms of stack should assume an average of 2.1

 

[Turiko]

I would design it so that there is enough mem/capacity to handle an average of 2.1 fragments per packet. imo 2 is not enough and 3 is overkill.

So the actual code should be able to handle 3+ frags per packet, but the capacity in terms of stack should assume an average of 2.1

That's what I thought. Thank you.

 

[stoke]

Surely you're wrapping the data in PPPOE packges? So you should not be dealing with fragmentation at all if you can force the PPPOE packages to be properly formed at tne correct packet size?

 

[Turiko]

This product does not do PPPoE it is intended to be plugged into a router/firewall.

I've not examined the packets in sufficient detail yet- I am still doing planning. At the moment I've just completed the ethernet driver, only to discover a better ethernet chip came out while I was busy anyway as soon as I can get sample of that chip will I make further decisions.