[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] RE: SEAL, PMTUD, IPv6 header bloat, header compression
Hi Robin,
>-----Original Message-----
>From: Robin Whittle [mailto:rw@firstpr.com.au]
>Sent: Sunday, April 06, 2008 4:24 AM
>To: Routing Research Group; Templin, Fred L
>Subject: SEAL, PMTUD, IPv6 header bloat, header compression
>
>Hi Fred,
>
>in two messages in the "Is ISATAP a practical solution" you
>mentioned some things to do with the problem of Path MTU Discovery
>for ITRs to ETRs, fragmentation of packets etc. - and your SEAL
>proposal which intended to help with these.
>
> http://tools.ietf.org/html/draft-templin-seal-04 (new today)
>
>I haven't read SEAL in detail yet.
Now at -05; hopefully not to change for a while.
>I wrote, in:
>
> http://psg.com/lists/rrg/2008/msg01112.html
>
> I have a dimmer view of IPv6 than many IETF folks. I think 64
> bit addresses would have been better. With 128, there are 32
> bytes of address in every packet - which seems like overkill
> when there are millions of people sending two-way streams of 50
> VoIP packets a second with only 20 bytes of payload. However
> there are creative uses of the extra bits, such as Six/One.
>
> This address burden gets worse with any map-encap tunneling
> header, so I am keen to keep Ivip encapsulation as minimal as
> possible: IP-in-IP. LISP involves a LISP header and therefore a
> UDP header as well. I am also keen to avoid anything like a
> SEAL header, at least on the shorter packets in any map-encap
> tunnel.
>
>and:
>
> The one thing I could imagine making IPv4 completely unworkable
> would be every cellphone on the planet having its own mobile
> public IP address, which I think could be done with the
> map-encap approach to mobility. Since there are 3.3 billion
> such devices now, IPv4 could never do that. But then think of
> those bloated IPv6 addresses chewing up bandwidth on cell-phone
> radio links carrying streams of VoIP packets.
>
>
>However when I wrote this, I was also thinking of the map-encap
>headers with at least two sets of IPv6 source and destination
>address (inner payload packet and the encapsulation header) going
>over the mobile link - which would be horrible. This isn't right.
>In the TTR-based model of mobility with map-encap schemes, the
>mobile node (MN) has its own (potentially proprietary) 2-way tunnel
>to the nearby TTR. Apart from the basic IPv6 header, the lengthy
>additional header stuff to do with the map-encap scheme I was
>discussing in the first two paragraphs above only travels in the
>ITR->ETR part of the path, and the TTR plays the role of ETR. So
>map-encap headers, SEAL headers etc. don't need to go to the MN.
Correct - no map-encaps or SEAL headers to the MN. SEAL
is for use in router-to-router tunneling in-the-network.
Low-end systems would not see the encapsulation headers;
they would only see their native-link first-hop routers
which would eventually deliver their packets to an ITR
or from an ETR somewhere else in the network.
>You responded to the third paragraph above:
>
>> Again, header compression has been proposed.
>
>OK - a suitably sophisticated header compression on the radio link
>would be able to find the repetitive parts of streams of VoIP
>packets etc. and compress their IPv6 headers, and perhaps their UDP
>are RTP headers significantly.
>
>Header compression could also be done in the MN <--> TTR protocol.
OK; I will read about TTR.
>>> I am also keen to avoid anything like a SEAL header, at least
>>> on the shorter packets in any map-encap tunnel.
>>
>> Including the SEAL header on large packets and omitting
>> it on smalls is certainly an idea to be taken seriously
>> and not to be dismissed w/o further consideration. However,
>> reasons we might not want to do that include:
>>
>> 1) multiple encapsulation formats on the same link; could
>> confuse both tunnel endpoints and middleboxes
>>
>> 2) omission of SEAL header reduces identification to
>> only 16 bits; may not be sufficient for duplicate
>> packet and/or off-link attack detection
>>
>> What are your thoughts on this?
>
>I will have to read the SEAL material before commenting further, but
>I think it is really important to avoid extra headers unless they
>are really needed - especially for the vast streams for small
>packets such as VoIP.
As above, the low-end systems and edge networks would not see
the extra headers; only the in-the-network router-to-router
tunnels would.
>> BTW, the idea of extending the IPv4 ID to 32 bits in a
>> manner similar to the way SEAL does it is not new. The
>> earliest proposal to do this (which I came across after
>> publishing SEAL) was from Steve Deering on the mtudwg
>> mailing list in Feb. 1990:
>>
>> http://ipvlx.org/mtudwg-log
>>
>> but I wouldn't be surprised if there were still
>> earlier proposals. The primary difference between what
>> SEAL is doing and what Steve articulated was that Steve
>> proposed a new IPv4 option, whereas SEAL proposes a new
>> IPv4 protocol.
>
>New IPv4 header options are not practical since DFZ routers won't
>handle them quickly (or perhaps at all?).
Right; I am only giving an historical account and not
a proposal to use IP options. See also: "IP Options are
not an Option":
http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf
> A map-encap system
>definitely needs a solution to the PMTUD and fragmentation problems.
> I am hoping to do it in Ivip without any extra headers in the
>traffic packets, and with a new protocol for ITRs probing PMTU to
>ETRs. As our discussions last year showed, this is a really
>difficult business.
Based on what I can tell, a lot of people have been
thinking about this for a long time now. For years, I
have been striving for perfection, but am now beginning
to doubt that is possible. Instead, I think what SEAL
has now is "pretty good" and perhaps even "good enough".
>I won't be updating my plans, currently
>summarised at:
>
> http://www.firstpr.com.au/ip/ivip/pmtud-frag/
>
>until I have read your SEAL proposal and given it a lot more thought.
Thanks - Fred
fred.l.templin@boeing.com
>
> - Robin
>
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg