Subject: RE: IPv6 and Tiny Fragments

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 25 Nov 2005 02:50:47 -0800

Hi Mohacsi,

LWAPP encapsulation, IPv6-in-IPv6 etc. 

Thanks.
Vishwas

-----Original Message-----
From: Mohacsi Janos [mailto:[email-masked]] 
Sent: Friday, November 25, 2005 4:11 PM
To: Vishwas Manral
Cc: Pekka Savola; [email-masked]
Subject: RE: IPv6 and Tiny Fragments

On Fri, 25 Nov 2005, Vishwas Manral wrote:

> Hi Pekka,
>
> That sounds good. We seem to be coming from different direction but to
> the same thing.
>
> I however would prefer to be closer to 800, to allow more levels of
> encapsulation, especially the first header.
>
> I do not agree with Mohacsi because the 1280 limit will not allow
> further encapsulations, without fragmentation.

What further encapsulation are you referering to? If I would be a 
implementer and I would have to pass packets bigger than MTU.
I would take as much content as I can into the first fragmented packet
and 
so on until there is content left. I would use fragment at least minimum

MTU (size >1280).

>
> Pekka, besides the RFC does not state how we treat M flag as 0 and
> fragment Offset as 0?
>

Janos Mohacsi
Network Engineer, Research Associate
NIIF/HUNGARNET, HUNGARY
Key 00F9AF98: 8645 1312 D249 471B DBAE  21A2 9F52 0D1F 00F9 AF98

> Thanks,
> Vishwas
> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: Friday, November 25, 2005 3:12 PM
> To: Vishwas Manral
> Cc: Mohacsi Janos; [email-masked]
> Subject: RE: IPv6 and Tiny Fragments
>
> Hi,
>
> On Fri, 25 Nov 2005, Vishwas Manral wrote:
>> I think that is the minimum Link MTU and not the smallest size
> non-last
>> fragment.
>>
>> Can you point me to the RFC/ draft which says what you stated?
>
> This is a good point.  Let me copy a part of Elwyn Davies's message on
> the list on September:
>
>
> Date: Wed, 21 Sep 2005 23:14:26 +0100
> From: Elwyn Davies <[email-masked]>
> To: Bob Hinden <[email-masked]>, Brian Haberman
> <[email-masked]>
> Cc: [email-masked]
> Subject: Taking RFC2460 (base IPv6) spec to full standard - issues
> outstanding
> ....
> [outstanding issues in core IPv6 spec before moving to full standard]
> ?       Fragment reassembly algorithm - should explicitly forbid
> overlapped
>         fragments and possibly require that non-final fragments are
> (say) at
>         least 1024 bytes.
>
> The minimum IPv6 fragment size is not specified AFAICT.
>
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
>

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

---

From: Mohacsi Janos <[email-masked]>
Date: Fri, 25 Nov 2005 12:11:18 +0100 (CET)

> LWAPP encapsulation, IPv6-in-IPv6 etc.

I have to study LWAPP encapsulation - currently I have no opinion. In the 
IPv6-in-IPv6 encapsulation It is completely possible that tunnel endpoint 
has to fragment the packet. Multiple level encapsulation might cause 
multiple level of fragmentation. This is the price of if encapsulation....

Regards,

Janos Mohacsi

---

From: Stig Venaas <[email-masked]>
Date: Fri, 25 Nov 2005 12:26:06 +0100

> multiple level of fragmentation. This is the price of if encapsulation....

Right, so I think a typical implementation would as you say, let each
fragment have the Path MTU size (at least 1280), while the last might
be smaller.

But assume you have say a 1500 byte packet. Instead of fragmenting so
that the first fragment has say 1280 bytes, why not split packet in
two equal sized fragments. That way you avoid further fragmentation
which might occur if there is further encapsulation taking place later
on the path.

BTW, I know that fragmentation order might vary, e.g. Linux at times
send (or used to send) fragments in reverse order.

Stig

---

From: Mohacsi Janos <[email-masked]>
Date: Fri, 25 Nov 2005 12:35:27 +0100 (CET)

> send (or used to send) fragments in reverse order.

You halving approach not very useful for 9K packets, which is tend to be 
common on GE and 10GE.

Regards,

Janos Mohacsi

---

From: "Edgar E. Iglesias" <[email-masked]>
Date: Fri, 25 Nov 2005 12:43:30 +0100

> You halving approach not very useful for 9K packets, which is tend to be 

The sender could when doing fragmentation make an effort to send the smallest
amount of fragments and distribute the payload as equally as possible across
the fragments. Would that improve things?

Best regards
-- 
        Programmer
        Edgar E. Iglesias <[email-masked]> 46.46.272.1946

---

From: Stig Venaas <[email-masked]>
Date: Fri, 25 Nov 2005 12:56:21 +0100

[...]
> You halving approach not very useful for 9K packets, which is tend to be 

Just an example. Let's say you need say a minimum of 8 fragments to
make sure each fragment <= path MTU (M). The obvious thing to do is
to send 8 fragments where 7 have the size M, and one has some size
N <= M.

If N < M, you could try to make some of the fragments of size M
smaller, and increase N.

So let's say you have some 9100 byte packet that needs to be
fragmented to 1280 byte sizes. Instead of sending something like

7 x 1280, 1 x 140 (well, I'm not really account for size of
frgmentation header).

You can send 4 x 1138, 4 x 1137.

Again, just an example to illustrate that it might be reasonable
to send smaller fragments than the MTU size. And in some cases,
as with further encapsulation, this might be useful.

However, there would never be a reason to send fragments of size
less than half of the Path MTU (IMO), since then you could send
fewer fragments.

Stig