Subject: RE: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 4 Dec 2001 14:15:30 +0100

> Saving 16 or 32 bytes in the datagram is IMO basically irrelevant.

=> "irrelevant" to what ?? Not to BW consumption obviously.

 Hesham
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 Dec 2001 15:42:00 +0200 (EET)

> => "irrelevant" to what ?? Not to BW consumption obviously.

IMO, there comes a point when adding complexity to save a few bytes off 
every datagram may not be worth worrying _too much_ about it.

On slow, high-delay links (e.g.  9600bit/s) this might make some sense,
but these need a header compression _anyway_ so I don't think there are
any additional gains there.

An example.  While typing this, I captured with tcpdump the IPv6 datagrams
I was typing.  It appears that in a second, on average ~5-15 packets were
sent in one direction.  Each of these had an IPv6 header of 40 bytes and
TCP header plus basically a few characters -- ~60 bytes.  Taking the
average of 10 packets/sec, this amounts to about 4800 bit/sec of frantic
typing.  With additional 32 bytes, the requirement would have been 7360
bits/sec.

Contrast that to e.g. 64kbit/s ISDN connection, 56kbit/s modem, 10Mbit/s
Ethernet and you don't see a huge difference; if you want to transfer 
data, you'd use bigger packet size anyway.

Basically the required additional capacity would be something from
(40+32+1)/(40+1) = 78% (very small packets) to (40+32+1428)/(40+1428) = 2%
[or even less].

The first is not a problem if you don't have too slow link (where you'd
need ROHC or something anyway), and latter is rather irrelevant IMO.

Not every byte counts.

Which is why I don't see much of a point in adding complexity to only sate 
one, rather minor need (slow, high-delay links).

But there are other gains to be gained in the address deletion though,
which make it more interesting than just saving a few bytes.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Dec 2001 15:13:20 +0100

Does anybody know how well ROHC would perform in the specific case
Steve's draft covers? If it does as well, or almost as well, then
I would agree with Pekka- any case where the bandwidth is critical
should be using ROHC anyway.

  Brian

---

From: Francis Dupont <[email-masked]>
Date: Tue, 04 Dec 2001 16:32:46 +0100

In your previous mail you wrote:

   Steve's draft covers?

=> ROHC explicitely supports encapsulation (i.e. addresses which are
always the same are dropped).

   If it does as well, or almost as well, then
   I would agree with Pekka- any case where the bandwidth is critical
   should be using ROHC anyway.
   
=> I agree (this argument applies near each time where the bandwidth
is critical) but I believe the purpose is not to save bandwidth but
to replace special devices by a more general one:
 - replace one shot source routing by IPV6_NO_SRC
 - replace home address option by IPV6_NO_DEST
There are already degenerated (i.e. optimizable) cases of tunnel in
mobility, IPsec, ... To have a general mechanism is a good idea,
at least as a basis for discussion.

But I'd like to see an example (the text is not very clear about
the new non-terminal header format, it seems it has exactly the
same layout than the IPv6 header) and of course the security section.
For instance I'd like to know how ESP is applied (is the inner header
compressed, if it is the case there is a security issue, if it is not
the case common applicability cases are lost).

Regards

[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 Dec 2001 17:34:44 +0200 (EET)

> at least as a basis for discussion.

Exactly the point I was making.

Saving bandwidth won't hurt, but that's definitely not the reason to do 
it.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 05 Dec 2001 12:53:17 -0800

> Not every byte counts.

The more bytes, the more they count.

> one, rather minor need (slow, high-delay links).

Mobility works well with wireless links, and a lot of wireless
links are just exactly as you describe.  It's not a minor need --
in fact it is the precise area of application which has motivated 
the entire effort as best I can tell.

Regards,
Charlie P.