[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