Subject: Piggybacking: final thoughts ? Was RE: [mobile-ip] MIPv6 - Focus of the security discussion

From: "Koodli Rajeev (NRC/MtView)" <[email-masked]>
Date: Wed, 24 Oct 2001 13:27:52 -0400

Hello Hesham,
 
this is continuing to be a long discussion. Anyway, I think we are
probably converging on some issues. Let me make a (bold) try in
summarizing the discussion.
 
- "tight channel" is the main focus. 
- I say on such a channel, HC is likely used. You have concurred. My
claim is HC will work with piggybacking. You seem to agree. However,
there is something below to iron out.
- My position is that if a link supports IPv6, destination option is a
given. You seem to agree. I say this means it is supporting
piggybacking. You say if it does, it has performance issues. I say we
don't design based on a link's performance..
- Service disruption is moot to me. See comments below.
 
Finally, my position is that removing piggybacking is not an option.
However, including some text in the draft stating that some links MAY
have performance issues to consider when piggybacking is fine with me. I
think this may be the way forward.
 
Please see additional comments below.
 
Regards,
 
-Rajeev

	Rajeev, 

I don't know where I poorly explained my point, but 
let me see if this works. 
Let's assume we have a tight channel with a large 
RTT delay and was designed with the assumption that HC 
is used. Hence, there is no 40 byte slack in the channel 
because the assumption was always that HC exists 
and the IP header was not accounted for. This is 
obviously for the case where this channel is "tight" 
due the low BW requirement of the service running on it. 

[Rajeev] Since HC is used, how was the context initialized in the first
place ? You have to send IR packets first. So, the tight channel must
have means for initializing the context. Furthermore, it must have means
to re-establish it when necessary. 

When a device starts sending an occasional (additional) ext header 
that causes the payload to be split across more than 
one radio frame, then significant delays will be encountered 
for that payload. If this is a real time payload (like voice) 
then the delays makes this datagram useless when it 
arrives at the other end. Hence service disruption has 
already taken place. 

[Rajeev]  When HC is used, the payload should not be split. When it is
not used, what is the magnitude of this service disruption ? One
packetization interval ? Real-time applications work with play-back
adjustments schemes that account for the inherent jitter (i.e.,
variation in delay for back to back packets) in packet-switched
networks. So, your "performance" argument is moot.

	Note that I didn't say anything about the packet being 
dropped above. I will assume that the implementation 
of this channel will not drop the packet. So the packet 
will still (eventually) be delivered to the other end where 
the BU is processed. 

Now In the above (_realistic_) scenario, 
was the service disrupted due to the piggybacking ? Yes 
Will the BU be delivered to the other end ? Based on the 
assumption above: Yes 
Is this radio link breaking RFC2460 ? No because the 
packet was not dropped. 
Did the user gain anything from piggybacking ? No. 

[Rajeev]  This is not a good enough reason to _remove_ piggybacking. I
see no quantifiably significant service disruption. By piggybacking, we
are only making use of base IPv6 which the link claims to support.

	So I don't understand why you're in favour of mandating 
piggybacking. 

	This covers some of your answers, more comments below: 

	        I am in favor of option 1 you mention below. This is in
line with
general IP protocol design. Any performance considerations could be
stated in the draft in some form.
For instance, we could state that "..if the BAck does not return after
transmitting a Binding Update BU_PIGGY_TIMES, the sending node must send
a BU without piggybacking". BU_PIGGY_TIMES, a non-zero integer, is a
configurable parameter. 

	=> I don't think that's a good idea. It shouldn't take a few BUs
and dropped packets for us to "guess" whether piggybacking
is needed or not. 

	[Rajeev:]There was an e-mail earlier from Greg Daley on how to
do this better. 

=> No that doesn't solve the problem. Michael already 
responded to that. 

[Rajeev]  I will have to look into it for more details. If channel
asymmetry is the issue, that channel should still consider if it is
supporting IPv6.

	In fact I don't know why you say it's in line with general IP
protocol
design ?? Could you explain what that is ?
In the Fast Handoffs work for v4 and v6, the design teams have
been modifying parts of MIP to -for example- get the AR to
start forwarding before receiving a BU, why was this acceptable ?
Why didin't we just say link layers should be desinged to allow
for MIP signalling ?

	[Rajeev]  Well, do they eliminate piggybacking ? How do they
violate base IPv6 specification ?  

=> I didn't refer to piggybacking ! They violate MIPv6 which clearly 
states that forwarding to a new CoA must be done based on 
the reception of an authenticated BU. They don't violate 
the base IPv6, but MIPv6. Is that allowed ? If so then I 
don't understand the "violation" argument. 

[Rajeev]  This is a good argument to discuss. In FMIPv6 at least, if you
keep the old CoA, there is no requirement for BU. If the network does
host routing, it is not violating anything either. So, I am not sure
what they are violating.. On the other hand, if we remove piggybacking
on a link that claims to support IPv6, that is a violation. We are
designing protocols based _solely_ on _a_ link's idiosyncrasies. That
seems like violation to me..

Well some of us did, but the WG decided that both philosophies
are needed to support existing link layers. BETH is one example.
So I don't think your logic is in line with the previous WG decisions
on similar topics.

	[Rajeev] Performance optimizations are fine as long as the base
protocol is not violated. Here, by saying that we will disallow
piggybacking, you are saying that we don't support IPv6 destination
options in arbitrary packets.  

=> The example I showed above does NOT disallow 
piggybacking, but it shows that it can be disruptive to 
the services. Anyway, I don't think your charaterisation 
is accurate. Destination options are certainly supported 
(the Home address option is for one). The point is that, 
the behaviour by which a node signals to the other end 
needs to be optimised to minimise service disruption. 
In this case the optimisation is to send the MIPv6 signalling 
message on a separate channel, hence eliminate piggybacking. 

[Rajeev]  If you are, by saying we do not disallow piggybacking,
referring to having piggybacking but make a recommendation that some
links MAY have performance issues, I can live with that. Regarding your
statement above concerning Destination Option: I specifically mentioned
that a link has to be able to support destination option in _arbitrary_
packets. I know I have a lot to learn, but please don't disrespect
whatever I already happen to know!

There is nothing wrong with sending DST options in separate 
IP packets. RFC 2460 did not say that all the information 
MUST be piggybacked. 

[Rajeev]  Right. I am not saying DON'T send BU in separate packets. I
_am_ saying that that's not the only way to send a BU. Piggybacking is
use of destination option, and if a link supports IPv6, I see no reason
why I must not use it!

	        Hesham

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 24 Oct 2001 13:47:58 -0500

Hi Rajeev,
  In your text, would it be OK to replace
piggybacking
with
piggybacking BU/Back?

Regards,

"Koodli Rajeev (NRC/MtView)" wrote:

>   Hello Hesham,this is continuing to be a long discussion. Anyway, I
> think we are probably converging on some issues. Let me make a (bold)
> try in summarizing the discussion.- "tight channel" is the main
> focus. - I say on such a channel, HC is likely used. You have
> concurred. My claim is HC will work with piggybacking. You seem to
> agree. However, there is something below to iron out.- My position is
> that if a link supports IPv6, destination option is a given. You seem
> to agree. I say this means it is supporting piggybacking. You say if
> it does, it has performance issues. I say we don't design based on a
> link's performance..- Service disruption is moot to me. See comments
> below.Finally, my position is that removing piggybacking is not an
> option. However, including some text in the draft stating that some
> links MAY have performance issues to consider when piggybacking is
> fine with me. I think this may be the way forward.--

Behcet

---

From: Michael Thomas <[email-masked]>
Date: Wed, 24 Oct 2001 12:52:00 -0700 (PDT)

What has not been established is whether the
particular form of header compression you are
singling out -- ROHC -- will be of much practical
use over the kind of L2 Hesham is talking about.
That is, ROHC+RTP over a fixed slot scheduler.  As
far as I can tell, it would require the roof of
allocation (that is, full header) for the slots
which sounds like a not very good fit.

	     Mike

Koodli Rajeev (NRC/MtView) writes:
 > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 > <HTML><HEAD>
 > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
 > <TITLE>RE: [mobile-ip] MIPv6 - Focus of the security discussion</TITLE>
 > 
 > <META content="MSHTML 5.00.3013.2600" name=GENERATOR></HEAD>
 > <BODY>
 > <DIV>&nbsp;</DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>Hello 
 > Hesham,</SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>this 
 > is continuing to be a long discussion. Anyway, I think we are probably 
 > converging on some issues. Let me make a (bold) try in summarizing the 
 > discussion.</SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>- 
 > "tight channel" is the main focus. </SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>- I 
 > say on such a channel, HC is likely used. You have concurred. My claim is HC 
 > will work with piggybacking. You seem to agree. However, there is something 
 > below to iron out.</SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>- My 
 > position is that if a link supports IPv6, destination option is a given. You 
 > seem to agree. I say this means it is supporting piggybacking. You say if it 
 > does, it has performance issues. I say we don't design based on a link's 
 > performance..</SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>- 
 > Service disruption is moot to me. See&nbsp;comments below.</SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001>Finally, my position is that removing piggybacking is 
 > not an option. However,&nbsp;including some text in the draft stating that some 
 > links MAY have performance issues to consider when piggybacking is fine with me. 
 > I think this may be the way forward.</SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=750194216-24102001>Please 
 > see additional comments below.</SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001>Regards,</SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001>-Rajeev</SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001>&nbsp;</SPAN></FONT></DIV>
 > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
 > class=750194216-24102001></SPAN></FONT>&nbsp;</DIV>
 > <BLOCKQUOTE 
 > style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
 >   <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
 >   size=2><BR>&nbsp;</DIV></FONT>
 >   <UL>
 >     <UL>
 >       <P><FONT color=#0000ff face=Arial size=2>Rajeev, </FONT></P></UL></UL>
 >   <P><FONT color=#0000ff face=Arial size=2>I don't know where I poorly explained 
 >   my point, but </FONT><BR><FONT color=#0000ff face=Arial size=2>let me see if 
 >   this works. </FONT><BR><FONT color=#0000ff face=Arial size=2>Let's assume we 
 >   have a tight channel with a large </FONT><BR><FONT color=#0000ff face=Arial 
 >   size=2>RTT delay and was designed with the assumption that HC </FONT><BR><FONT 
 >   color=#0000ff face=Arial size=2>is used. Hence, there is no 40 byte slack in 
 >   the channel</FONT> <BR><FONT color=#0000ff face=Arial size=2>because the 
 >   assumption was always that HC exists</FONT> <BR><FONT color=#0000ff face=Arial 
 >   size=2>and the IP header was not accounted for. This is </FONT><BR><FONT 
 >   color=#0000ff face=Arial size=2>obviously for the case where this channel is 
 >   "tight"</FONT> <BR><FONT color=#0000ff face=Arial size=2>due the low BW 
 >   requirement of the service running on it.</FONT> <BR><FONT color=#0000ff 
 >   face=Arial size=2><SPAN class=750194216-24102001></SPAN></FONT></P>
 >   <P><FONT color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001>[Rajeev]&nbsp;Since HC is used, how was the context 
 >   initialized in the first place ? You have to send IR packets first. So, the 
 >   tight channel must have means for initializing the context. Furthermore, it 
 >   must have means to re-establish it 
 > when&nbsp;necessary.&nbsp;</SPAN></FONT></P>
 >   <P><FONT color=#0000ff face=Arial size=2>When a device starts sending an 
 >   occasional (additional) ext header</FONT> <BR><FONT color=#0000ff face=Arial 
 >   size=2>that causes the payload to be split across more than</FONT> <BR><FONT 
 >   color=#0000ff face=Arial size=2>one radio frame, then significant delays will 
 >   be encountered</FONT> <BR><FONT color=#0000ff face=Arial size=2>for that 
 >   payload. If this is a real time payload (like voice)</FONT> <BR><FONT 
 >   face=Arial><FONT color=#0000ff size=2>then the delays makes this datagram 
 >   useless when it <BR>arrives at the other end. Hence service disruption has 
 >   <BR></FONT></FONT><FONT size=2><FONT color=#0000ff><FONT face=Arial>already 
 >   taken place. <BR><SPAN 
 >   class=750194216-24102001></SPAN></FONT></FONT></FONT></P>
 >   <P><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
 >   class=750194216-24102001>[Rajeev]&nbsp;&nbsp;When HC is used, the payload 
 >   should not be split. When it is not used, what is the magnitude of this 
 >   service disruption ? One packetization interval ? Real-time applications work 
 >   with play-back adjustments schemes that account for the inherent jitter (i.e., 
 >   variation in delay for back to back packets) in packet-switched networks. So, 
 >   your "performance" argument is moot.</SPAN></FONT></FONT></FONT></P>
 >   <P><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
 >   class=750194216-24102001></SPAN></FONT></FONT></FONT>&nbsp;</P>
 >   <UL>
 >     <UL>
 >       <P><FONT color=#0000ff face=Arial size=2>Note that I didn't say anything 
 >       about the packet being </FONT><BR><FONT color=#0000ff face=Arial 
 >       size=2>dropped above. I will assume that the implementation 
 >       </FONT><BR><FONT color=#0000ff face=Arial size=2>of this channel will not 
 >       drop the packet. So the packet</FONT> <BR><FONT color=#0000ff face=Arial 
 >       size=2>will still (eventually) be delivered to the other end where 
 >       </FONT><BR><FONT color=#0000ff face=Arial size=2>the BU is 
 >       processed.</FONT> </P></UL></UL>
 >   <P><FONT color=#0000ff face=Arial size=2>Now In the above (_realistic_) 
 >   scenario, </FONT><BR><FONT color=#0000ff face=Arial size=2>was the service 
 >   disrupted due to the piggybacking ? Yes</FONT> <BR><FONT color=#0000ff 
 >   face=Arial size=2>Will the BU be delivered to the other end ? Based on 
 >   the</FONT> <BR><FONT color=#0000ff face=Arial size=2>assumption above: 
 >   Yes</FONT> <BR><FONT face=Arial><FONT color=#0000ff size=2>Is this radio link 
 >   breaking RFC2460 ? No because the <BR>packet was not dropped. 
 >   <BR></FONT></FONT><FONT size=2><FONT color=#0000ff><FONT face=Arial>Did the 
 >   user gain anything from piggybacking ? No. <BR><SPAN 
 >   class=750194216-24102001></SPAN></FONT></FONT></FONT></P>
 >   <P><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
 >   class=750194216-24102001>[Rajeev]&nbsp;&nbsp;This is not a good enough reason 
 >   to _remove_ piggybacking. I see no quantifiably significant service 
 >   disruption. By piggybacking, we are only making use of base IPv6 which the 
 >   link claims to support.</SPAN></FONT></FONT></FONT></P>
 >   <P><FONT size=2><FONT color=#0000ff><FONT face=Arial><SPAN 
 >   class=750194216-24102001></SPAN></FONT></FONT></FONT>&nbsp;</P>
 >   <UL>
 >     <UL>
 >       <P><FONT color=#0000ff face=Arial size=2>So I don't understand why you're 
 >       in favour of mandating </FONT><BR><FONT color=#0000ff face=Arial 
 >       size=2>piggybacking. </FONT></P>
 >       <P><FONT color=#0000ff face=Arial size=2>This covers some of your answers, 
 >       more comments below:</FONT> </P><BR>
 >       <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial size=2>I am 
 >       in favor of option 1 you mention below. This is in line with</FONT><FONT 
 >       face=Arial><BR></FONT><FONT face=Arial size=2>general IP protocol design. 
 >       Any performance considerations could be</FONT><FONT 
 >       face=Arial><BR></FONT><FONT face=Arial size=2>stated in the draft in some 
 >       form.</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>For 
 >       instance, we could state that "..if the BAck does not return 
 >       after</FONT><FONT face=Arial><BR></FONT><FONT face=Arial 
 >       size=2>transmitting a Binding Update BU_PIGGY_TIMES, the sending node must 
 >       send</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>a BU 
 >       without piggybacking". BU_PIGGY_TIMES, a non-zero integer, is 
 >       a</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>configurable 
 >       parameter.</FONT><FONT face=Arial> </FONT></P></UL>
 >     <P><FONT color=#0000ff face=Arial size=2>=&gt; I don't think that's a good 
 >     idea. It shouldn't take a few BUs</FONT><FONT face=Arial><BR></FONT><FONT 
 >     color=#0000ff face=Arial size=2>and dropped packets for us to "guess" 
 >     whether piggybacking</FONT><BR><FONT color=#0000ff face=Arial size=2>is 
 >     needed or not.</FONT><FONT face=Arial> </FONT></P>
 >     <P><FONT color=#0000ff face=Arial size=2>[Rajeev:]There was an 
 >     e-mail&nbsp;earlier from Greg Daley on how to do this better.</FONT> </P></UL>
 >   <P><FONT color=#0000ff face=Arial size=2>=&gt; No that doesn't solve the 
 >   problem. Michael already </FONT><BR><FONT color=#0000ff face=Arial 
 >   size=2>responded to that.</FONT> <BR><FONT color=#0000ff face=Arial 
 >   size=2><SPAN class=750194216-24102001></SPAN></FONT></P>
 >   <P><FONT color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001>[Rajeev]&nbsp;&nbsp;I will have to look into it for 
 >   more details. If channel asymmetry is the issue, that channel should still 
 >   consider if it is supporting IPv6.</SPAN></FONT></P>
 >   <P><FONT color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001></SPAN></FONT>&nbsp;</P>
 >   <UL><BR>
 >     <P><FONT color=#0000ff face=Arial size=2>In fact I don't know why you say 
 >     it's in line with general IP protocol</FONT><FONT 
 >     face=Arial><BR></FONT><FONT color=#0000ff face=Arial size=2>design ?? Could 
 >     you explain what that is ?</FONT><BR><FONT color=#0000ff face=Arial 
 >     size=2>In the Fast Handoffs work for v4 and v6, the design teams 
 >     have</FONT><BR><FONT color=#0000ff face=Arial size=2>been modifying parts of 
 >     MIP to -for example- get the AR to</FONT><BR><FONT color=#0000ff face=Arial 
 >     size=2>start forwarding before receiving a BU, why was this acceptable 
 >     ?</FONT><FONT face=Arial><BR></FONT><FONT color=#0000ff face=Arial 
 >     size=2>Why didin't we just say link layers should be desinged to 
 >     allow</FONT><BR><FONT color=#0000ff face=Arial size=2>for MIP signalling 
 >     ?</FONT><FONT face=Arial><BR></FONT></P>
 >     <P><FONT color=#0000ff face=Arial size=2>[Rajeev]&nbsp;&nbsp;Well, do they 
 >     eliminate piggybacking ? How do they violate base IPv6 specification ?&nbsp; 
 >     </FONT></P></UL>
 >   <P><FONT color=#0000ff face=Arial size=2>=&gt; I didn't refer to piggybacking 
 >   ! They violate MIPv6 which clearly </FONT><BR><FONT color=#0000ff face=Arial 
 >   size=2>states that forwarding to a new CoA must be done based on 
 >   </FONT><BR><FONT color=#0000ff face=Arial size=2>the reception of an 
 >   authenticated BU. They don't violate</FONT> <BR><FONT color=#0000ff face=Arial 
 >   size=2>the base IPv6, but MIPv6. Is that allowed ? If so then I 
 >   </FONT><BR><FONT color=#0000ff face=Arial size=2>don't understand the 
 >   "violation" argument.</FONT> <BR><FONT color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001></SPAN></FONT></P>
 >   <P><FONT color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001>[Rajeev]&nbsp;&nbsp;This is a good argument to 
 >   discuss. In FMIPv6 at least, if you keep the old CoA, there is no requirement 
 >   for BU. If the network does host routing, it is not violating anything either. 
 >   So, I am not sure what they are violating.. On the other hand, if we remove 
 >   piggybacking on a link that claims to support IPv6, that is a violation. We 
 >   are designing protocols based _solely_ on _a_ link's idiosyncrasies. That 
 >   seems like violation to me..</SPAN></FONT></P>
 >   <P><FONT color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001></SPAN></FONT>&nbsp;</P>
 >   <UL>
 >     <P><FONT color=#0000ff face=Arial size=2>&nbsp;<BR>Well some of us did, but 
 >     the WG decided that both philosophies<BR>are needed to support existing link 
 >     layers. BETH is one example.<BR>So I don't think your logic is in line with 
 >     the previous WG decisions</FONT><FONT face=Arial><BR></FONT><FONT 
 >     color=#0000ff face=Arial size=2>on similar topics.</FONT><FONT 
 >     face=Arial><BR></FONT></P>
 >     <P><FONT color=#0000ff face=Arial size=2>[Rajeev] Performance optimizations 
 >     are&nbsp;fine as long as the base protocol is not violated.&nbsp;Here, by 
 >     saying that we will disallow piggybacking, you are saying that we don't 
 >     support IPv6 destination options in arbitrary packets. &nbsp;</FONT></P></UL>
 >   <P><FONT color=#0000ff face=Arial size=2>=&gt; The example I showed above does 
 >   NOT disallow </FONT><BR><FONT color=#0000ff face=Arial size=2>piggybacking, 
 >   but it shows that it can be disruptive to</FONT> <BR><FONT color=#0000ff 
 >   face=Arial size=2>the services. Anyway, I don't think your 
 >   charaterisation</FONT> <BR><FONT color=#0000ff face=Arial size=2>is accurate. 
 >   Destination options are certainly supported</FONT> <BR><FONT color=#0000ff 
 >   face=Arial size=2>(the Home address option is for one). The point is that, 
 >   </FONT><BR><FONT color=#0000ff face=Arial size=2>the behaviour by which a node 
 >   signals to the other end</FONT> <BR><FONT color=#0000ff face=Arial 
 >   size=2>needs to be optimised to minimise service disruption. </FONT><BR><FONT 
 >   color=#0000ff face=Arial size=2>In this case the optimisation is to send the 
 >   MIPv6 signalling</FONT> <BR><FONT color=#0000ff face=Arial size=2>message on a 
 >   separate channel, hence eliminate piggybacking.</FONT> <BR><FONT color=#0000ff 
 >   face=Arial size=2><SPAN class=750194216-24102001></SPAN></FONT></P>
 >   <P><FONT color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001>[Rajeev]&nbsp;&nbsp;If you are, by saying we do not 
 >   disallow piggybacking, referring to having piggybacking but make a 
 >   recommendation that some links MAY have performance issues, I can live with 
 >   that. </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001>Regarding your statement above concerning Destination 
 >   Option: I specifically mentioned that a link has to be able to support 
 >   destination option in _arbitrary_ packets. I know I have a lot to learn, but 
 >   please don't disrespect whatever I already happen to know!</SPAN></FONT></P>
 >   <P><FONT color=#0000ff face=Arial size=2>There is nothing wrong with sending 
 >   DST options in separate</FONT> <BR><FONT color=#0000ff face=Arial size=2>IP 
 >   packets. RFC 2460 did not say that all the information</FONT> <BR><FONT 
 >   color=#0000ff face=Arial size=2>MUST be piggybacked.</FONT> <BR><FONT 
 >   color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001></SPAN></FONT></P>
 >   <P><FONT color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001>[Rajeev]&nbsp;&nbsp;Right. I am not saying DON'T send 
 >   BU in separate packets. I _am_ saying that that's not the only way to send a 
 >   BU. Piggybacking is use of destination option, and if a link supports IPv6, I 
 >   see no reason why I must not use it!</SPAN></FONT></P>
 >   <P><FONT color=#0000ff face=Arial size=2><SPAN 
 >   class=750194216-24102001></SPAN></FONT>&nbsp;</P>
 >   <UL>
 >     <P><FONT color=#0000ff face=Arial 
 >     size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hesham</FONT><FONT 
 >     face=Arial> </FONT></P></UL></BLOCKQUOTE></BODY></HTML>

---

From: Cedric Westphal <[email-masked]>
Date: Wed, 24 Oct 2001 15:35:19 -0700

> which sounds like a not very good fit.

You hit the point, Mike: Hesham's L2 link would require a roof
allocation for the slots, and ROHC would give the slack for
piggybacking.

C.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 24 Oct 2001 17:59:05 -0400

Law of objectivity:
If an I-D is from others then you are very objective about it
otherwise if the I-D is from your colleague/company then objectivity disappears.

(the above is a very generic law and applies in other domains such as professors and
students; parents and children, and so on)

Cedric Westphal wrote:

> >  >              Hesham Soliman wrote:

> --

Behcet

---

From: Michael Thomas <[email-masked]>
Date: Wed, 24 Oct 2001 16:35:01 -0700 (PDT)

> allocation for the slots, and ROHC would give the slack for

   I guess I'd have to question the sanity of
   somebody running a complex state machine like
   ROHC or CRTP if the only realized bandwidth
   savings were for the occasional binding update
   you could sneak in. If I were a cellular
   operator, I think I'd rather have a header
   compression scheme which worked well on the
   vast majority of packets and paid the price
   for exception packets (= BU) on an as needed
   basis.

   As I keep pointing out, this is why the cable
   MAC uses Payload Header Suppression for
   DOCSIS because it gives them that ability.
   I sure hope this is no surprise to the
   ROHC WG. You guys are making me nervous that
   it is.

	Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 24 Oct 2001 17:15:10 -0700 (PDT)

Koodli Rajeev (NRC/MtView) writes:
  >You say if it does, it has performance issues. I say we

_Oh_??? There's a difference between being a slave
to link layers and not considering them at all. If
I believed that this was a narrow situation that
is only related to a single link layer which needs
to be redesigned for IP anyway, you would not be
getting any arguments from me. However, I believe
that this slotting problem that we've been
describing is a fundamental engineering tradeoff
when you have a shared media, such as radio.

I have repeatedly asked for a concrete example of
a shared media which provides QoS guarantees which
would substantially benefit from piggybacking. You
still have not done that. 

 > Finally, my position is that removing piggybacking is not an option.

Everything is an option. The draft is not done.

	      Mike

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 24 Oct 2001 17:30:23 -0700

You cannot stop an IPv6 host from including destination option in
_arbitrary_ packets. In that sense, removing piggybacking is not an
option. Any link that claims to carry IPv6 must know how to handle
destination option in any arbitrary packet. As I indicated, IF performance
is the issue, appropriate text can be added in the draft.

Regards,

-Rajeev

---

From: Michael Thomas <[email-masked]>
Date: Wed, 24 Oct 2001 17:44:05 -0700 (PDT)

I don't know how this can be made to be any
clearer than has been tried by the endless
attempts by many different people. Since you won't
answer the one pertinent question, there is no
point to this discussion.

	 Mike

---

From: "David R. Oran" <[email-masked]>
Date: Sat, 27 Oct 2001 11:50:14 -0400

Small refinement to what Mike Thomas was saying:

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Michael Thomas
> Sent: Wednesday, October 24, 2001 8:15 PM
> To: [email-masked]
> Cc: 'ext Hesham Soliman (EPA)'; 'ext Michael Thomas'; Michael 
> A. Ramalho
> Subject: Piggybacking: final thoughts ? Was RE: [mobile-ip] 
> MIPv6 - Focus of the security discussion
> 
> 
I believe Mike's right for links which are shared point-to-multipoint
AND have a long channel arbitration time for the centralized scheduler
to grant access. The channel slotting amortizes the access time and
minimizes the lost bandwidth due to control overhead. The efficiency
improvement on both scores is actually quite dramatic.

If these were in fact really oddball links, then it would in fact be
appropriate to just dump L3 packets in any old way and tell the link
designers to cope. The reality is that these links are pretty common
(DOCSIS, cellular radio, 802.11, etc.) and the designers didn't just
throw in slotting because they were stupid. They wanted to provide a L2
with decent jitter bounds for traffic that cares about delay dispersion
without paying an exhorbitant bandwidth cost in control overhead.

So, my 2 cents is that it does make sense to tune MIP to run well over
slotted, centrally arbitrated channels.

What seems to be of issue is whether the cases of other bandwidth
constrained non-slotted channels (e.g. low speed pt-pt links) gain
enough from things like piggybacking to make a tradeoff which will
likely hurt performance on slotted channels. My personal view is that
even over non-slotted channels header compression makes the additional
gain of piggybacking quite small, and layer 2 blocking (multiple IP
packets in one layer 2 frame) eliminates nearly all of the rest of the
potential gain.

> Everything is an option. The draft is not done.
Unfortunately, I fear that we have argued this back and forth so much
without progress, that consensus seems unlikely. I don't know frankly
where we go from here...

Dave Oran

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sat, 27 Oct 2001 17:30:57 -0700

Hello Dave,

> improvement on both scores is actually quite dramatic.

There isn't any essential conflict between channel slotting
vs. IP,, or vs. IPv6, or vs. Mobile IPv6, or vs. sending Binding
Updates in a destination option with payload.  In order to handle
IP over a rigorously slotted link, one _could_ reasonable expect to
have some slicing and dicing going on, which is already _mandated_
for those links if they run IPv6 (section 5,RFC 2460).  If you want
to run IPv6 over a link that cannot support 1280 byte MTU, then
I reckon you're going to have all sorts of problems.

What if we assume the link CAN run IPv6 (or even just IPv4, for
that matter!)?  With that assumption, then I claim that we will
always see a performance improvement if one can include destination
options with payload, vs. sending destination options in a separate
packet.  You may then ask what the numbers are.  I'm not quite
ready to cite them, but I'm still taking bets that it will be
a positive number (increased performance) vs. a negative number
(a performance loss).

What do you think?

> slotted, centrally arbitrated channels.

Agreed!

>                                             My personal view is that

I am sure that we will see a variation of the performance gains over
various links.  I am also sure the variation will range over positive
numbers only, for links that are engineered to fulfill the mandates of
IPv6.  Since a receiver does not need extra complexity to handle such
packets, then the performance gains will go to those systems where the
implementers carry out the necessary extra work so that mobile nodes
sending packets can see the improvement.  For some links, it may not
make sense to invest the time for implementation.  For other links it
will.  But to change the rules so that no one can ever benefit from the
performance enhancement, on any possible link, seems quite ill advised
to me.

I am sure that _nobody_ is making suggestions that will cause cellular
links that perform _worse_, given reasonable assumptions.  Furthermore,
I am also sure that future cellular links will be engineered to handle
IP{,v6} data _better_ than current links do.  Then, it would be a shame
to look back and observe how short-sighted it was to deploy a mobility
protocol that _could not_ fulfill the performance gain in the same easy
ways.  We may even discover that the performance gain is not killer,
but only an incremental improvement.  But the whole history of cellular
has been putting together more and more incremental improvements.
No one technique solves all the problems, and performance leaks do have
a way of accumulating.

> without progress, that consensus seems unlikely. I don't know frankly

I don't have that fear.  I think that with enough reasonable conversation
between reasonable engineers we will get to the point of agreement.
I'll try to do my part.

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 28 Oct 2001 08:26:32 -0800 (PST)

> without progress, that consensus seems unlikely. I don't know frankly

   This can all be boiled down to this tradeoff:

   Piggybacking: an optimization which cannot be used to
     any appreciable gain for the flows on shared bandwidth 
     constrained links; specifically makes using 2401
     compliant IPsec impossible, and provides no means
     for automated key distribution for strong authentication

   Non-piggybacking: loses bandwidth/latency gains on other
     L2's, but primarily where the optimization is either
     unnecessary or can be accommodated by equivalent L2 
     mechanisms. Allows use of RFC 2401 standard IPsec, and 
     retains  the ability to use standard IPsec key distribution
     mechanisms (IKE, KINK).

		      Mike