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
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
