🚀 go-pugleaf

In article <mbt.718324346@Able.MKT.3Com.Com>, mbt@ESD.3Com.COM (Brad Turner) writes:
> ...
> >The only IP fragmenting that an FDDI-ether bridge will usually need to
> >do is of UDP packets.  UDP packets are datagrams, and have no sequence
> >numbers of any kind.  If you don't have FDDI-ether-FDDI networks, the
> >initial MSS negotiation in TCP will pick 1500.  This is consistent with
> >the TCP/IP lore (and RFC) that considers fragmenting harmful.
>  
> Hmmm what about bulk transfers (e.g. FTP, SMTP) that are TCP based? If a
> connection is to a local station (i.e. same net/subnet) won't the node
> attempt to use max size packets of the native media for the TCP connection?
> For example a FTP transfer from a FDDI station to an ethernet station that
> is bridged. Won't the FDDI node attempt to use max size FDDI frames for the
> transfer since the IP address of the destination is on the same net/subnet
> as the FDDI station?


Doesn't every (reasonable) TCP implementation start with an MSS,
Maximum Segment Size, option in the first TCP header, along with the
SYN flag?  Isn't the value of the MSS no larger than the local MTU, the
maximum transmission size?  In other words, on every reasonable TCP/IP
implementation, whether the application is for a "bulk transfer" or
not, the two ends of the virtual circuit will choose the minimum of
each end's max transmit.  size.

This has nothing to do with the hallowed recommendation that if the
remote end is not on the same IP network (sometimes subnetwork), your
TCP implementation should propose to use 512 or a similar number (e.g.
576) for the max. segment size.  Please notice that 512 and 576 are far
smaller than 1500, and have unfortunate effects on bulk transfers.  I
understand from what I've been told and from some experiments that the
old 512 restriction no longer applies in most of the Internet.


vjs