Subject: RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

From: "Glenn Morrow"<[email-masked]>
Date: Thu, 14 Feb 2002 14:40:21 -0600

Why can't we just leave these engineering tradeoffs to particular products?

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Thursday, February 14, 2002 11:32 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation 
> 
> 
> > How can the DT recognize there is a *potential* benefit, but decide
> > to kill piggybacking?
> 
> Brian,
> 
> There is a potential benefit it lots of things - I can 
> envision benefits
> in carry BUs as XML over http (but there might be some 
> disadvantages as well
> :-)
> 
> The issue is the engineering tradeoff.
> 
>   Erik
> 
>

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 15 Feb 2002 17:39:13 +0100

=> Ah, ok. Sure, that negotiations will take 
place anytime between turning on the device
and sending the BU. It's implementation 
(system) dependant I suppose.

Also, please note
  > that even if there is a separate control channel,
  > correct IP operation would require that
  > negotiation be carried out even before splitting
  > naked Binding Updates down that channel, so
  > nothing is gained in this regard by axing the
  > functionality.

=> By 'naded' BU you mean in a separate
packet right? You don't mean sending 
the ext header alone and then recombining
that at the receiving router do you?

I'll assume the former, yes a request
for a certain channel is needed before
sending the packet. The point is, separation
of the packets will mean that each will
get the 'expected' treatment. 

The other alternative is to take each extension
header and place it on a separate channel.
But I think this is obviously unworkable 
because some parts of the packet might get
lost and some not. Since some parts might
require retransmission and some don't, then
things will get very messy. 
So it's just a lot simpler to send them in
2 separate IP packets. 

Hesham

  > Regards,
  > Charlie P.

---

From: Phil Roberts <[email-masked]>
Date: Fri, 15 Feb 2002 11:58:05 -0500

Not really.  The DT makes recommendations which are subject to working group
discussion and decision.  The DT has made
a recommendation and the WG is discussing it.  Once some decision is reached
we'll ask the DT to go off and draft text or
(use some text that someone else has drafted).

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Friday, February 15, 2002 11:58 AM
To: [email-masked]
Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

Glenn, Charlie, and all,
  I have a feeling that Charlie and Glenn and possibly others coming up with
solutions of their own defeats the purpose of the design team set up by the
WG cochairs and to my knowledge agreed by the WG.
  I suggest that DT makes a conference call with these people once and for
all and gets their input and continues its work.
  It could also be noted that whatever the solutions to be agreed this time
under time pressure may always be improved upon later on with additional
RFCs or RFC xxx-bis's. It is not end of the world.
  Let me also note that I only have a very primitive knowledge of the
security issues.

Regards,

Glenn Morrow wrote:

Hesham,
 
I too, am starting to feel like a broken record so I think we should perhaps
digress into the link layer space of the particular access technology you
believe will be damaged. Please let me know which access specific link layer
technology you are referring to? This will be doing access work but gee if
it is going to keep access specific arguments out of the IETF work, I
suppose I'm game for coming up with an access and media specific solution to
the problem i.e. I guess I'll try to help improve the least common
denominators.
 
Here are some proposals: 
 
- SAR the packet.
- Send it over a signaling channel with additional delay.
- Make the channels more flexible to handle spurious changes in bandwidth.
 
Keep in mind that the almost negligable delay, if any,  induced by some of
these solutions will not happen very often. I also urge you to drive down
the highway right now with an existing cell phone and see if you notice some
delay during handoff. I know you could get a perfect one under some
circumstances but just keep doing it and you'll find that some "engineering
choices" have been made on particular deployments, let alone particular
products. My point here is "get real". The last proposal which I think is
what the Nokia contingent has been saying doesn't even have this theoretic
no delay mumbo jumbo point either.
 
Also keep in mind that  the mobile could be configured to tell the CN(MN)
not to send it bundled in the future after the 1st one. This also seems like
a prudent engineering choice. But gee, I haven't seen any of these mythical
sort of IP VOIP 3G handsets deployed that would have this problem in the
future and the way the financiers and vendor plans are going lately with
respect to alternatives I'm not sure if we ever will. 
 
There - now I've been completely politically incorrect but I hope this
points out again just like an old broken record the flaw in the arguments
against bundling. And again, I would like to remind people in a completely
agnostic manner that this is the IETF and not a cellular SDO and that to
technically use the excuse for decision you have used below would signal to
me that the IETF is behaving like an access specific cellular SDO.
 
Thanks,
 
Glenn

behcet

---

From: "Glenn Morrow"<[email-masked]>
Date: Fri, 15 Feb 2002 13:14:23 -0600

Another point I would like to make about bundling is that this is something
that MIPv6 signaling can do by the way it has been designed and that other
signaling technologies  (perhaps a better term might be layer) can not do
it. So if you remove this distinguishing item, it might re-open or give
credence to the old argument about which signaling should be used for node
mobility.  

regards,

Glenn