Subject: Comments on WIMP and MTU Handling

From: Margaret Wasserman <[email-masked]>
Date: Tue, 2 Mar 2004 19:58:43 -0500

As I just discussed at the meeting mic, some of the multi6 proposals 
that involve a mid-Internet layer wedge (including WIMP and NOID) 
have an issue with IP fragmentation and reassembly.  If an ID/Loc 
layer will exist conceptually below the fragmentation/reassembly 
function, it is problematic for it to add optional bytes to the 
packet (such as a header or IP option that may or may not be 
included).  There are some possibilities for dealing with this:

     - Run the ID/Loc separation between the Network and Transport 
layers instead.
     - Reduce the MTU presented to upper layers, so that there is 
always room for the optional header.

If you choose the second option, though, there is no advantage to 
mechanisms that try to avoid the need to add a header (such as the 
special next header values used in NOID).

WIMP also adds another twist on this problem by forbidding 
fragmentation of packets that contain WIMP headers.  There is no 
indication of how/if the upper layers will cooperate to make this 
possible, or what impacts this requirement might have on Path MTU 
discovery.

Margaret

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 3 Mar 2004 10:42:14 +0900

Exactly - as if we needed application interaction for multi6, like you
had for ipv6 itself...

Spencer

---

From: Geoff Huston <[email-masked]>
Date: Wed, 03 Mar 2004 14:58:05 +1100

http://www.potaroo.net/presentations/multi6-arch.pdf

regards,

      Geoff

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 3 Mar 2004 14:05:26 +0900

Hi Margaret,

[...]

> special next header values used in NOID).

I am not sure i understand this argument...
i mean, if you present a reduced mtu to the upper layers, but the additional
header is not included, you are actually sending less bytes, which means
that you are consuming less bandwidth, so others can use it.

so i do see a benefit on this approach, since you are saving some bandwidth

am i missing something?

regards, marcelo

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 03 Mar 2004 14:18:25 +0900

> that you are consuming less bandwidth, so others can use it.

huh?

if you shrink the MTU, you're putting more of your available link
capacity into packet headers because you now need more packets to
carry a given payload.

					- Bill

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 2 Mar 2004 21:43:08 -0800 (PST)

> special next header values used in NOID).

If I understand you correctly the issue appears when the shim adds
different amount of headers depending on its state.

For instance, in the NOID case it would add bytes to the packet when
establishing the host-pair context state but once that state
is established there are no bytes added.
One can view this as an artifact of the piggybacking of the ULP messages
on the state establishment protocol.

There are multiple approaches to this that do not require 
moving the shim above fragmentation:
 - Make the piggybacking dynamic. If the ULP message plus the shim message
   fit in one packet do the piggybacking. Otherwise send two separate
   packets. (If the context is created due to a TCP open exchange this will
   piggyback since the SYN packets are small.)
 - Make the interface between the transports and IP handle more dynamic
   MTUs. The transport packetization could ask IP "how large packet can I send
   now" where the answer is a function of the state of the host-pair context
   in the shim layer. 
 - As you suggest, lower the MTU that the transport sets to take
   into account the maximum amount of shim-layer header that might be
   added by the shim. But this is more pessimistic than the above two choices.

  Erik

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 3 Mar 2004 20:06:39 +0900

Hi Bill,

> capacity into packet headers because you now need more packets to

I agree with you.

There are three different scenarios, IMHO.

The best case, the complete MTU is presented to the upper layer, so it can
be used complete
The second case, is when a reduced MTU is presented but the additional
header is not included, so less bytes are transmited.
The worst case is when a reduced MTU is presented and the header is included
in the packet.

My point was about that the second and the third are different and that the
second case was better than the third one.

Is this correct?

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 3 Mar 2004 21:31:23 +0100

On 3-mrt-04, at 1:58, Margaret Wasserman wrote:

> If an ID/Loc layer will exist conceptually below the 
> fragmentation/reassembly function, it is problematic for it to add 
> optional bytes to the packet (such as a header or IP option that may 
> or may not be included).  There are some possibilities for dealing 
> with this:

>     - Run the ID/Loc separation between the Network and Transport 

As opposed to network and link or transport and application???

Doing address agility first and then fragmentation makes implementing 
the former in a middlebox much harder, if not impossible.

> always room for the optional header.

Also problematic. What if the MTU already is 1280 or not much larger, 
and the new MTU would be lower than 1280? But ignoring this for a 
moment, it should be just fine to have the transport learn a small MTU 
at one point in time (because a large option needs to be added) and 
then at a later time the full MTU is available because there is no need 
for an option at this time.

An alternative would be to fragment the segment coming from the 
transport layer without telling the transport layer about this, and 
then add the option to one of the fragments. This makes it necessary 
for the part of the stack doing the fragmenting to be aware of the 
multihoming solution, though.

Another way to get around this is to send the options as independent 
messages. However, since firewalls won't recognize these packets they 
may not make it to the destination host. Solution for that would be to 
add a transport layer header without any payload data so firewalls can 
see which session the packet belongs to (if any).

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Mar 2004 14:37:47 +0100

So, we have found a new item for
draft-lear-multi6-things-to-think-about-01

under "2.3.3 Does your solution expand the size of an IP packet?"

such as:

What impact does your solution have on MTU size issues? Can the IPv6
standard MTU of 1280 bytes be supported?

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 04 Mar 2004 23:24:52 +0900

Brian;

> standard MTU of 1280 bytes be supported?

It is trivially easy to do so with fragmentation (see how IPv6
standard tunneling support 1280B of MTU, which actually is a
fallacy) that the statement should be:

   What impact does your solution have on MTU size issues? Can the
   IPv6 standard MTU of 1280 bytes be supported without additional
   fragmentations at any layer?

							Masataka Ohta