Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-rfc3782-bis-02.txt

From: [email-masked]
Date: Fri, 06 May 2011 11:15:03 -0700

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF.

    Title         : The NewReno Modification to TCP's Fast Recovery Algorithm
    Author(s)     : T. Henderson, et al
    Filename      : draft-ietf-tcpm-rfc3782-bis-02.txt
    Pages         : 16
    Date          : 2011-04-20
    
   RFC 5681 documents the following four intertwined TCP
   congestion control algorithms: slow start, congestion avoidance, fast
   retransmit, and fast recovery.  RFC 5681 explicitly allows
   certain modifications of these algorithms, including modifications
   that use the TCP Selective Acknowledgement (SACK) option (RFC 2883),
   and modifications that respond to "partial acknowledgments" (ACKs
   which cover new data, but not all the data outstanding when loss was
   detected) in the absence of SACK.  This document describes a specific
   algorithm for responding to partial acknowledgments, referred to as
   NewReno.  This response to partial acknowledgments was first proposed
   by Janey Hoe.  This document obsoletes RFC 3782.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc3782-bis-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 9 May 2011 09:15:16 +0100

Tom,

Maybe a stupid question, but section 4.2 reads like some cross over with
the Eifel RFC3522 / RFC4015 algorithms, which are encumbered by IPR -
some partially open (but non-GPL) and commercial implementations appear
to be forbidden for Eifel. [For completeness, this section was already
in 3782].

https://datatracker.ietf.org/ipr/171/

How does this RFC3782bis circumvent this patent? (Without the special
wording of the Ericsson IPR, a standard reciprocity IPR wouldn't pose
any problem, for a standards-track document IMHO).

Unfortunately, the IPR doesn't state the exact patents owned by Ericsson
- but Eifel is generic enough that any heuristic making use of
timestamps for loss recovery of some form is likely to be in violation
of their claimed patents...

Thanks,

Richard Scheffenegger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Freitag, 06. Mai 2011 20:15
> To: [email-masked]
> Cc: [email-masked]
> Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-rfc3782-bis-02.txt
>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 23 May 2011 09:29:04 -0700

> From: Scheffenegger, Richard [mailto:[email-masked]]
> Sent: Monday, May 09, 2011 1:15 AM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: RE: [tcpm] I-D ACTION:draft-ietf-tcpm-rfc3782-bis-02.txt
> 
> Tom,
> 

Richard,
Sorry for the delay in replying to your question.  I discussed this offline with the NewReno authors and we believe that the use of timestamps in RFC 3782 is quite different than the use in RFC 3522 (Eifel).  

- Tom