Subject: Re: jumbo frame of GbE and IPv6 -- A proposal

From: Perry Lorier <[email-masked]>
Date: Mon, 01 Aug 2005 23:24:15 +1200

(Sorry for being late on the replies, been busy recently :)

> When a tunnel is used, there may be many L2 segments (connected by
> L2 switches) with diverse MTUs separating the tunnel endpoints in what
> otherwise appears as a single-hop to L3. And, the set of L2 segments
> will often be different in the forward and reverse directions.

Hrm, good point.  Although IMHO since tunnels are things that are likely
to be configured by the network admin (modulo 6to4 etc) if the admin
screws it up it's their own fault.  The point is to make it work "by
default".  We can't cover every possible eventuality of admins
sabotaging their own network.

However, on the flipside, maybe we should just do it symmetrically (and
send packets both ways).  It doubles the bandwidth, and halves the
failure cases :)

> I asked this earlier, but where are we at in the decision process
> for native IPv6 vs tunneled?

I'm not sure I understand the question.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Perry Lorier <[email-masked]>
Date: Mon, 01 Aug 2005 23:35:14 +1200

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.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 1 Aug 2005 11:21:49 -0700

> -----Original Message-----
> From: Perry Lorier [mailto:[email-masked]] 
> Sent: Monday, August 01, 2005 4:24 AM
> Cc: IETF IPv6 Mailing List
> Subject: Re: jumbo frame of GbE and IPv6 -- A proposal
> 
> screws it up it's their own fault.

It might be a bit premature to discount the importance of
automatic tunnels in actual deployment scenarios.

> The point is to make it work "by

The question was intentionally vague and might not be answerable
in a definitive way. At least, different inviduals would likely
answer the question in very different ways if it were posed to
them on a one-on-one basis. In hindsight, the question really
didn't add anything to the technical discussion and might have
been better were it omitted.

Fred
[email-masked]