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

From: "Kuntal Chowdhury"<[email-masked]>
Date: Fri, 15 Feb 2002 11:08:22 -0600

>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.
 
It is always a bad idea to rush into a solution under time pressure to get
an RFC number. This kind of approach always results in backward
compatibility nightmares.
 
-Kuntal

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]]
Sent: Friday, February 15, 2002 10: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: Behcet Sarikaya <[email-masked]>
Date: Fri, 15 Feb 2002 11:25:02 -0600

Kuntal,
  Recently RFC2002 was modified to become RFC2002bis and then RFC3220.
Did this cause backward compatibility nightmares?
  I think that you are talking about some cyber authority making RFCs 
that never change.
We all know in the telecom world, the standards change sometimes completely!

  So I stand by my argument.

Kuntal Chowdhury wrote:

> > 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.
>
>  
>
> It is always a bad idea to rush into a solution under time pressure to 
> get an RFC number. This kind of approach always results in backward 
>       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. 
>>
>>      
>>
>>     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
>

-- 
Behcet