headers
Duke, Martin | 1 Oct 2003 02:27
Picon
Favicon

RFC 1323.bis

A comment on the RFC 1323 revision Internet-Draft:

Although the original contained no such thing, a section (maybe an
appendix?) that discusses some of the corner cases in which the RTT
measurement will be wildly inaccurate:

A)      DATA 5, ACK 37, TS 12 -------------> (has long RTO, for whatever
reason)

		  (lost) --------------- ACK 6, ECHO 12

				<sometime later, data becomes available>

		  <------------------- DATA 37, ACK 6, ECHO 12

B) 	  DATA 3, TS 12 -------------------->  (again, long RTO)

		   (lost) --------------- ACK 4, ECHO 12, rcv window = 0

		  <---------------------- ACK 4, ECHO 12, rcv window =
foo

and states that these cases are rare enough that we're willing to accept
the problem.

Martin
Permalink | Reply | 0 comments |
headers
Yogesh Prem Swami | 1 Oct 2003 22:23
Picon

draft-swami-tcp-lmdr-01.txt

Hello folks,

An update for 'draft-swami-tcp-lmdr-01.txt' is now available from:

http://www.ietf.org/internet-drafts/draft-swami-tcp-lmdr-01.txt

Any comment or suggestion will be highly appreciated.

Thanks

--yogesh
Permalink | Reply | 0 comments |
headers
Sally Floyd | 1 Oct 2003 23:08

draft-ietf-tsvwg-newreno-01

At the last IETF, I sent the following email to the mailing
list:

>From the tsvwg meeting at the IETF, now in progress, here are
>the issues to track (in the next week) for WG Last Call,
>for the NewReno TCP:
>
>* Add a note to the section on "Implementation issues for the data 
>sender" saying that the sender might want a separate flag to record
>whether it is in the Fast Recovery procedure, for robustness
>with window updates and out-of-order acks.
>
>* Add an implementation note about taking care of sequence wrap.
>
>* Address the issue raised by Andrei Gurtov about whether
>packets are sent in response to dup acks in those cases
>when Fast Recovery is not invoked (because of bugfix).

We have made changes addressing these issues, and submitted a
revised version of the internet-draft, which is now ready for
Working Group Last Call:

http://www.icir.org/floyd/papers/draft-ietf-tsvwg-newreno-01.txt
http://www.icir.org/floyd/papers/draft-ietf-tsvwg-newreno-01.ps

We have made no changes to the basic algorithm specified in 
Section 3 of the draft.

Addressing the third item in the list involved adding a discussion
in Section 6 about possible heuristics that a sender may use for
(Continue reading)

Permalink | Reply | 501 comments |
headers
Internet-Drafts | 2 Oct 2003 16:50
Picon
Favicon

I-D ACTION:draft-ietf-tsvwg-newreno-01.txt,.ps

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title		: The NewReno Modification to TCP's Fast Recovery 
                          Algorithm
	Author(s)	: S. Floyd, T. Henderson, A. Gurtov
	Filename	: draft-ietf-tsvwg-newreno-01.txt,.ps
	Pages		: 20
	Date		: 2003-10-2
	
RFC 2581 [RFC2581] documents the following four intertwined TCP
congestion control algorithms: Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery.  RFC 2581 [RFC2581] explicitly allows
certain modifications of these algorithms, including modifications
that use the TCP Selective Acknowledgement (SACK) option [RFC2018],
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.  The NewReno mechanism uses an
algorithm for responding to partial acknowledgments that was first
proposed by Janey Hoe in [Hoe95].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-newreno-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yogesh Prem Swami | 2 Oct 2003 18:26
Picon

Udate for draft-swami-tsvwg-tcp-dclor-02.txt

Hello,

An updated DCLOR draft is now available from:

http://www.ietf.org/internet-drafts/draft-swami-tsvwg-tcp-dclor-02.txt

Thanks
Yogesh
Permalink | Reply | 0 comments |
headers
Mark Allman | 6 Oct 2003 21:12

Re: draft-ietf-tsvwg-newreno-01


> We have made changes addressing these issues, and submitted a
> revised version of the internet-draft, which is now ready for
> Working Group Last Call:
>  
> http://www.icir.org/floyd/papers/draft-ietf-tsvwg-newreno-01.txt
> http://www.icir.org/floyd/papers/draft-ietf-tsvwg-newreno-01.ps

I read through the document and sent the authors a few minor
comments.  Nothing major.  My opinion is that the document is ready
to go.

allman

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/
Permalink | Reply | 501 comments |
headers
Pekka Savola | 6 Oct 2003 17:33
Picon

I-D ACTION:draft-ietf-v6ops-ipv4survey-trans-03.txt (fwd)

Hi,

Remember us asking for feedback on the "IPv4 address usage survey" a
couple of weeks ago?

Well, the document has been revised a bit (actually twice :-), and I
believe it should address the comments received:

http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-trans-03.txt

Please check it out and see that it's factually correct, the
recommendations in section 7 seem reasonable, etc.

In particular, we've found a new Full Standard, RFC 907 ("Host Access
Protocol"), which should be analyzed ;-)

Thanks,

Pekka
 writing as v6ops co-chair

---------- Forwarded message ----------
Date: Mon, 06 Oct 2003 11:11:56 -0400
From: Internet-Drafts <at> ietf.org
To: IETF-Announce:  ;
Cc: v6ops <at> ops.ietf.org
Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-trans-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kristine Adamson | 14 Oct 2003 16:57
Picon
Favicon

Status of TCP-ESTATS-MIB


Hello!
   We are looking into implementing the TCP-ESTATS-MIB in IETF draft
draft-ietf-tsvwg-tcp-mib-extension-03.txt.  We wondered what the status of
this draft was.  Is the WG still updating this MIB and will there be a new
version soon (maybe for the November IETF meeting)??  Thanks,

Kristine Adamson
IBM Communications Server for MVS: TCP/IP Development
Internet e-mail:adamson <at> us.ibm.com
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 14 Oct 2003 21:35
Picon
Favicon

I-D ACTION:draft-ietf-tsvwg-dsack-use-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title		: Using TCP DSACKs and SCTP Duplicate TSNs to Detect 
			  Spurious Retransmissions
	Author(s)	: E. Blanton, M. Allman
	Filename	: draft-ietf-tsvwg-dsack-use-02.txt
	Pages		: 7
	Date		: 2003-10-14
	
TCP and SCTP provide notification of duplicate segment receipt
through DSACK and Duplicate TSN notification, respectively. This
document presents a conservative method of using this information to
identify unnecessary retransmissions for various applications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-dsack-use-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-tsvwg-dsack-use-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Allman | 15 Oct 2003 16:13

Re: FW: Re: Last Call: 'Using TCP DSACKs and SCTP Duplicate T SNs to Detect Spurious Retransmissions' to Experimental RFC


Sourabh Ladha surfaced two issues with the dsack-use draft during
last call.  Ethan and I updated the draft (which is now
draft-ietf-tsvwg-dsack-use-02.txt in the archives) per the following.

>    * In the draft the following is about the SACK scoreboard: "We
>    assume the TCP sender has a data structure to hold selective
>    acknowledgment information (e.g., as outlined in [RFC3517])."
> 
>    Traditionally entries lying below the cumulative ACK point are
>    deleted from the scoreboard. But the DSACK information normally
>    comes after loss recovery has exited. So how long should the
>    scoreboard entries be maintained beyond what is required in
>    3517? (1 ACK after loss recovery exits in Fast retransmit; and
>    N Acks after loss recovery exits in a timeout (GoBackN)?)

Good catch.  We added a note that to use the scheme outlinedin the
draft a TCP implementation would have to keep more history in the
scoreboard. 

>    * In the Security Considerations, ECN Nonce 3540 is offered as
>      a protection. But 3540 calls for disabling Nonce Sum checks
>      for DupAcks. Is the draft suggesting some extension to 3540
>      that NS be checked for DupAcks carrying DSACK?

Also a good call.  We added some wiggle words to the draft.  That
is, per the above, the ECN nonce is not directly applicable to the
problem of preventing misleading DSACK (/DupTSN) notifications.
However, the principles of the ECN nonce are applicable and if we
found that protection against lying receivers to be necessary then
(Continue reading)

Permalink | Reply | 0 comments |

Gmane