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