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

From: "Glenn Morrow"<[email-masked]>
Date: Fri, 15 Feb 2002 10:45:24 -0600

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

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Friday, February 15, 2002 5:54 AM
To: [email-masked]'; [email-masked]
Subject: RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation 

Glenn,
 
I'm starting to feel like a broken record. It has been 
mentioned several times that a receiver that will be harmed
by piggybacking has no way of stopping this 
unless some negotiation is done. It seems that
most people are against this option. 
 
Hesham

-----Original Message-----
From: Glenn Morrow [mailto:[email-masked]]
Sent: Thursday, February 14, 2002 9:40 PM
To: [email-masked]; [email-masked]
Subject: RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation 

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

> -----Original Message----- 
> From: Erik Nordmark [ mailto:[email-masked]
<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: Behcet Sarikaya <[email-masked]>
Date: Fri, 15 Feb 2002 10:58:06 -0600

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.
>
> 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. 
>
>  
>
> 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