On Thu, 19 Aug 2004, Dick St.Peters wrote:
> Mathias Sundman writes:
>> On Thu, 19 Aug 2004, James Yonan wrote:
>>> Fragmenting doesn't make sense with TCP because TCP is a stream-based
>>> protocol, not a packet-based protocol. TCP communication is a stream
>>> of bytes without any packet boundaries, and so fragmenting at the
>>> application protocol level doesn't really make sense in this context.
>>> Now obviously, at the IP transport level, TCP is packetizing the
>>> stream, and that is the level at which things like MTU must be
>> So, are you saying that TCP will automatically shrink the packet size
>> even if path-mtu is broken so it does not receive any "fragmentaion
>> needed" ICMP packets?
>> If not how else do I solve the above problem if normal fragmentation is
>> not working and Path-MTU is broken (because of some router blocking ip
>> fragments and icmp "fragmentaion-needed" packets)?
> Mathias, TCP will automatically shrink the packet size if it can
> determine the maximum packet size (i.e., if path mtu discovery is not
> broken). However, if TCP can't determine the packet size for OpenVPN,
> how would you expect OpenVPN to determine it?
No, I didn't think so. That's why I though it would make as much sence
todo internal fragmentation when using TCP as transport as when using UDP.
Ofcource it should be solved by using PMTU or IP fragmentation in first
case, but when both these techniques are broken, I thougt you would have
the same problem regardless if you use UDP or TCP as transport.
> To answer my own question, I think TCP OpenVPN would be an interesting
> testbed for trying out some of the proposed pmtud replacements, such as
> gradually increasing the packet size until the no-response point is
If there are better ways to solve it so we can avoid internal
fragmentation, that's ofcource better...
Mathias Sundman (^) ASCII Ribbon Campaign
NILINGS AB X NO HTML/RTF in e-mail
Tel: +46-(0)8-666 32 28 / \ NO Word docs in e-mail