Subject: RE: [Mipshop] Warning: Bicasting and FMIPv6

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 11 Aug 2005 23:50:56 -0400

> I'm not indicating whether the IPR is justified or wrong,
 > just that Eifel isn't being recommended for implementation
 > by the group who is in charge of TCP maintenance.

=> But in MIPSHOP we couldn't possibly know why that is 
the case. 

 > 
 > I'm sure the TCPM WG chairs would have the details.

=> Sure, that's why I think details should accompany 
the news flash :)
I don't think it not being widely deployed is a great 
reason for us given the level of deployment of FMIP.

Hesham

 > 
 > Greg
 > 
 > Soliman, Hesham wrote:
 > > Greg, 
 > > 
 > > I think to be fair to the people that developed
 > > Eifel or sent the charges for the IPR (I'm sure none
 > > of them is on this list to defend themselves) we would
 > > need to know a lot more detail than that to dismiss
 > > Eifel. Like, who is this implementer?? was it a commercial
 > > implementation? 
 > > Of course an IPR holder has every right to demand payment
 > > for a commercial implementation. My understanding is 
 > > that the IPR statement for EIfel is RAND, which is 
 > > widely accepted in IETF. 
 > > 
 > > 
 > > Hesham
 > > 
 > >  > -----Original Message-----
 > >  > From: [email-masked] 
[mailto:[email-masked]]On
>  > Behalf Of Greg Daley
>  > Sent: Thursday, August 11, 2005 8:40 PM
>  > To: [email-masked]
>  > Subject: [Mipshop] Warning: Bicasting and FMIPv6
>  > 
>  > 
>  > Dear Mipshop,
>  > 
>  > I posted about this recently, but it was lost in the noise.
>  > 
>  > I was at the TCPM WG session where they were discussing
>  > a draft recommending TCP implementation practices.
>  > 
>  > During the session, there was consensus to move the Eifel
>  > algorithm, to an experimental section of the document
>  > _because_ it has not been widely deployed and because
>  > of existing uncertainties regarding IPR.
>  > 
>  > What was discussed in the session was the occurrance of
>  > an implementor being presented with a schedule of
>  > charges for licenses by an IPR holder.
>  > 
>  > Eifel has been described as a way to handle
>  > packet duplication events experienced due to bicasting
>  > in the draft (section 10):
>  > 
>  > http://www.ietf.org/internet-drafts/draft-elmalki-mobileip-bi
> casting-v6-06.txt
> 
> While the IETF (in compliance with its policy: BCP 79)
> will not take a position on the validity of the IPR claims,
> please be aware that Eifel is not widely implemented,
> and isn't likely to be implemented by default in TCP
> stacks, due to its experimental nature.
> 
> If bicasting is important, it may be worth investigating if
> another mechanism is available for reducing the effect of
> duplicated packets on upper layer protocol stacks.
> 
> Greg
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop
> 
> ===========================================================
> This email may contain confidential and privileged material for the sole use
>  of the intended recipient.  Any review or distribution by others is strictly
>  prohibited.  If you are not the intended recipient please contact the sender
>  and delete all copies.
> ===========================================================
> 
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Greg Daley <[email-masked]>
Date: Fri, 12 Aug 2005 15:30:03 +1000

Hi Hesham,

> => But in MIPSHOP we couldn't possibly know why that is 

The why isn't necessarily the salient point.
The existent fact is enough to warrant a notification.

I'm not predetermining the solution, just raising the issue.

> => Sure, that's why I think details should accompany 

Indeed.

I'll include as much information as I can now.

http://www.isi.edu/tcpm/agenda.html
(issue discussed here)

http://www.isi.edu/tcpm/ietf63/slides.pdf

Here's the draft session minutes:
http://www1.ietf.org/mail-archive/web/tcpm/current/msg01445.html

Here's the thread describing what TCPM is doing
http://www1.ietf.org/mail-archive/web/tcpm/current/msg01446.html

Here's another technology which may tackle a similar issue
(and has an IPR claim, but the assretion is that it is free
to implement).

http://www1.ietf.org/mail-archive/web/tcpm/current/msg01444.html

Perhaps it would be worth seeing if it also handles the
duplicate from bicast issue.

 > reason for us given the level of deployment of FMIP.

But if there exists and alternative technology with no claimed
IPR or "claimed free to implement" IPR, then the IETF typically
goes for that one.

It doesn't hurt to look for that case.

Greg