Re: [rrg] IRON: SEAL summary

[Robin Whittle <[e-mail]>]

Short version:    Low-key response to Fred's comments.

                  I think my SEAL summary V2 (msg05982) with Fred's
                  comments (msg05989) is OK.


Hi Fred,

Thanks, as always, for your reply:

>>>> Other items of state are listed in 4.3.3:
>>>>
>>>>     MHLEN   Constant mid-level header length.  In this attempt to
>>>>             describe SEAL, I will assume there is no need for these
>>>>             mid-level headers - between the outer IP header and the
>>>>             SEAL (or IPv6 fragmentation) header which precedes the
>>>>             encapsulated packet.  So I will assume this = 0.
>>>
>>> Actually, the mid-level headers occur between the *inner*
>>> IP header and the SEAL header.
>>
>> Something may need to be rewritten, since Figures 1 and 2 show
>> "mid-layer headers" after SEAL header.
> 
> I think the figures are OK. The top of the figure is
> the outermost header, and descending downwards through
> the figure shows successively more inner layers of
> encapsulation. Is it somehow confusing?

OK - for some reason I was thinking of UDP as a "mid-layer" header.

The 3rd dot point below Figure 2 mentions UDP as an outer layer
header - but it is may be difficult for readers to make the link from
the diagram to that text.  Also, I suggest you explain the purpose of
using UDP or any other headers after the IPv4/6 header, and before
the SEAL header.


>>>>     HLEN    Constant outer header length: 20 for IPv4 and 40 for
>>>>             IPv6 plus the length of the SEAL header (IPv4 only -
>>>>             8 bytes) or IPv6 Fragment Header (8 bytes).  So these
>>>>             are constants:
>>>>
>>>>                IPv4 28           IPv6 48
>>>
>>> I am going to work on this. I think what I will do is
>>> eliminate the need for the IPv6 header to include a
>>> fragment header and instead handle IPv6 segmentation
>>> and reassembly using SEAL the same as is currently
>>> documented for IPv4.
>>
>> OK - but as far as I know, in an IRON-RANGER scenario, the ITEs are
>> not intended to be continually sending a traffic packet by two or
>> more tunnel packets, whether by IPv4 fragmentation, IPv6
>> fragmentation or inbuilt SEAL segmentation - with the probable
>> exception of DF=0 IPv4 packets.
> 
> In the core, we will not require core routers to
> reassemble and those routers will use SEAL-FS.
> Toward the edges, there may be places that would
> benefit from using segmentation and reassembly,
> e.g., to hide the encapsulation artifact for
> tunnels. Those routers would use SEAL-SR.

OK:

   SEAL-SR is a functional superset of SEAL-FS, and requires that the
   tunnel endpoints support segmentation and reassembly of packets
   that are too large to traverse the tunnel without fragmentation.


>> I think that the IRON ID should attempt a summary of which parts of
>> SEAL are used for this CES system.  Likewise, it should contain a
>> reasonably self-contained description of what parts of RANGER and VET
>> are used.
> 
> OK.

OK.


>>>> Jumboframes
>>>> -----------
>>>>
>>>> ("Jumbograms" refer to IPv6 packets with special formats so they can
>>>> be longer than 2^16 bytes, and can be as long as 4 gigabytes.
>>>> Neither SEAL, Ivip's IPTM, nor any CES proposal attempts to deal with
>>>> these.)
>>>
>>> That is not correct; SEAL can accommodate Jumbograms
>>> using SEAL segmentation and reassembly if necessary.
>>> I think this is made clear in the case of IPv4 as the
>>> outer protocol, but I need to make sure to make it more
>>> clear in the IPv6 case.
>>
>> I think you could make SEAL to almost anything, but why would you
>> want any router to accept 64k and longer packets, up to 4 gigabytes
>> long, and fragment or segment then to be sent and later reassembled?
>>
>>   http://tools.ietf.org/html/rfc2675
> 
> Hi speed data centers that have 9KB MTU links and
> very low packet loss due to congestion might want to
> present a large MTU to TCP (e.g., 64B) then carry the
> segments as multiple 9KB packets using SEAL. 

OK - I understand this is just within these data centers and not to
other networks via the DFZ.

TCP would be fast and efficient with ~64kB packets, but the SEAL-SR
system in their network (in the sending and receiving hosts, perhaps)
would send them as ~9k packets.

There is already something like this going on with Ethernet drivers
or the Ethernet chip itself:

 http://www.firstpr.com.au/ip/ivip/ipv4-bits/actual-packets.html


> This also
> brings up the question of effectiveness of the link
> level CRC in detecting errored data as a function of
> the packet size. (Earlier works seemed to show that
> CRC-32 performance deteriorates for packet sizes
> larger than ~9KB.)
> 
> So, high speed data centers might want to use packet
> sizes that are larger than the underlying links can
> support natively.

Maybe so, but I am focusing on scalable routing and getting packets
across the DFZ.



>>>> For both IPv4 and IPv6, if the SH ignores PTBs, or if there is some
>>>> filtering between the ITE and the SH which drops PTBs, then there's
>>>> no way the SH is going to adapt its packets to the lengths required
>>>> by SEAL to send them without fragmentation, segmentation or whatever.
>>>
>>> It is true that SEAL does not attempt to fix MTU
>>> problems that occur in the end site in front of
>>> the ITE.
>>
>> Nor any other CES.  Only RFC 4821 in the TCP stack or the application
>> packetization layers can cope with this.  I think it should be fixed,
>> rather than coped with.
> 
> This can easily morph into a discussion of the
> end-to-end principles and how they would view
> MTU determination. I still think that the end
> systems would be better served to take MTU
> assurance into their own hands rather than
> rely on an untrustworthy network.

OK - we have different views on this.

 - Robin