Mark Smith wrote:
> Hi Iljitsch, Perry,
> 
> I'll admit I haven't been fully following your thread of discussion,
> I've been a bit busy on some other things (another reason why I like the
> simple solution - less thinking :-) )
> 
> Something to keep in mind for your solution. TCP announces the maximum
> segment size it can receive in the SYN or SYN/ACK segments, and I'm
> pretty sure these days that is derived directly from the (current) MTU
> value of the interface it is going to use at the time of the 3-way
> handshake. I'm pretty sure that irrespective of if PMTUD (or another
> local link method) discovers a larger possible PMTU value at a later
> time during the TCP connection, existing TCP connections will not be
> able to "burst" up to it.

The MSS option would be to the MTU of the outgoing interface[1], as
always.  The actual size sent will be limited to 1500 initially and will
grow as the size is detected.

The reason for this is that if you have this topology:

Host A <-1500-> Switch <-9k-> Host B

Then if Host B announces an MSS of 9k, host A will never try and send an
9k packet.  Even in the case of:

Host A <-9k-> Switch <-1500-> Switch <-9k-> Host B

Host A will refuse to forward a packet to Host B thats 9k until it has
fully probed the MTU up to 9k.

MSS is what the machine is capable of "receiving", and the host is
entirely capable of receiving a 9k MTU packet.  It says nothing about
the path MTU.

The initial packets of a TCP connection (SYN/SYNACK) are all assured to
be smaller than the IPv6 minimum maximum size (1280 bytes), by the time
you want to send some real data you hope that you're a good way through
your MTU probing.

> Assuming that you're not planning to modify TCP as well, this means that
> the knowledge of the "best" possible MTU that TCP can use must be known
> at the time of the initial 3-way handshake. This limitation possibly
> applies to other unicast or semi-unicast transport layer protocols too,
> such as SCTP.

I disagree.  MSS only says what the maximum size you can receive is
(Maximum Segment Size).  It doesn't say "This is the maximum size I
think I can receive, I might be able to receive larger"

> 
> Thinking about these solutions another way, all they're really
> attempting to do is to take the TCP-specific MSS mechanism, generalise
> it so it can be used for all transport layer unicast connections, and
> moving the mechanism to the network layer.

Well kinda yeah.  We're trying to determine the MTU of a neighbour,
rather than the MTU of an interface.

----
[1]: Well, minus the size of the headers etc.. You know what I mean.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to