Subject: RE: [mobile-ip] Piggybacking

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 13 Aug 2001 10:30:10 -0500

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Saturday, August 11, 2001 2:17 PM
To: [email-masked]
Subject: RE: [mobile-ip] Piggybacking

Glenn Morrow writes:
 > Michael, 
 > 
 > Please explain in more detail why you believe the performance would be
 > better without piggybacking. I would suspect the performance to be better
 > with piggybacking.

   It obviously depends on the particular link layer.
   However, for one example that I'm pretty familiar
   with -- DOCSIS cable -- it would better to separate
   them into two packets because you would then be able
   to reap the benefit of payload header supression 
   (PHS) as well as use concatenation to place both 
   packets on the same upstream grant request. 

GM] Balderdash on the upstream grant point - no gain one way or the other.
See my point below on the PHS.

 > I would also have some severe reservations about having a snooping ROHC
 > compression strategy drive the more pure IP standard.

   I don't understand what you mean here. ROHC would
   be greatly complicated if it had to consider
   piggybacking too. If we separate them, it could
   be made to look like a normal UDP packet which 
   ROHC already knows how to compress.

GM] Mike - so I guess you don't want to use Routing headers, IPSEC headers,
router alerts, home address options, etc.. etc.. etc.. because ROHC will
become more complex. It seems to me that you are being quite arbitrary in
your complexity argument. In my mind the complexity is not more than these
other header options. ROHC is a snooping technology. It is not a pure layer
3 solution. We should not drive the definition of MIPv6 based upon this
complexity argument of this snooping technology. The PHS is a similar thing
to ROHC and the same points apply. The BU will not be sent on every packet.
I don't see a problem with an exception here and there to improve the
overall end to end quality of service (route optimization) of the users
flows.

Glenn

---

From: Michael Thomas <[email-masked]>
Date: Mon, 13 Aug 2001 08:55:23 -0700 (PDT)

> See my point below on the PHS.

   I never claimed it was a gain. And my initial
   comment said that it may be neutral to a net
   gain. Concatenation substantially weakens the
   argument for piggybacking because the net extra
   cost is mainly a matter of bandwidth, which can
   be mitigated by normal compression techniques.

 > your complexity argument. 

   Not at all. If the headers are essentially static over the
   life of a flow, they can be compressed. If you inject
   variability into the flow -- like occassional
   BU's -- it becomes much more complicated. 

 > In my mind the complexity is not more than these

   Fine. On 10bT ethernet the marginal gains in
   bandwidth efficiency are not worth the added
   complexity in the stack, both for normal IP
   processing as Alper pointed out, path MTU
   considerations, as well as the complexities 
   that arise from things that have to deal with
   5-tuple processing like IPsec and RSVP. If 
   you don't believe that, then why shouldn't
   we piggyback ICMP messages on TCP connections?

		Mike