Subject: [Tsvwg] Re:ECN draft question

From: venkat venkatsubra <[email-masked]>
Date: Fri, 10 Nov 2000 11:27:50 -0600

I have a clarification to make in the following paragraph
in the draft (page 3, Option 1):

   In the first case, if the packet is either dropped or delayed, and at
   some point retransmitted by the data sender, then the retransmission
   is a result of a Fast Retransmit or a Retransmit Timeout for either
   that packet or for some prior packet in the same window of data.  In
   this case, because the data sender already has retransmitted this
   packet, we know that the data sender has already responded to an
   indication of congestion for some packet within the same window of
   data as the original packet.  Thus, even if this retransmitted packet
   is dropped in the network, or is delayed, with the CE bit set, and is
   later ignored by the data receiver as an out-of-window packet, this
   is not a problem, because the sender has already responded to an
   indication of congestion for that window of data. Communicating the
   indication of congestion with the CE bit for this retransmitted
   packet (if that indication is provided to the sender within the same
   window of data as a previously dropped packet) would not have
   resulted in any further reduction of the window by the sender.

When a retransmitted segment itself gets dropped, according to
rfc2481 it should be treated as a new instance of congestion and
would result in further reduction.  In the para above are you referring
to a retransmitted packet that was not retransmitted as a result of
Fast Retransmit or Retransmit Timeout ?

Thanks!
Venkat

[email-masked] wrote:

> Send tsvwg mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the web, visit
>         http://www1.ietf.org/mailman/listinfo/tsvwg
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of tsvwg digest..."
>
> Today's Topics:
>
>   1. I-D ACTION:draft-ietf-tsvwg-tcp-ecn-00.txt ([email-masked])
>
> --__--__--
>
> Message: 1
> To: IETF-Announce: ;
> Cc: [email-masked]
> From: [email-masked]
> Reply-to: [email-masked]
> Date: Tue, 07 Nov 2000 06:04:42 -0500
> Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-tcp-ecn-00.txt
>
> --NextPart
>
> 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           : TCP with ECN: The Treatment of Retransmitted Data
>                           Packets
>         Author(s)       : S. Floyd, K. Ramakrishnan
>         Filename        : draft-ietf-tsvwg-tcp-ecn-00.txt
>         Pages           : 9
>         Date            : 06-Nov-00
>
> This document makes recommendations for the use of ECN with
> retransmitted data packets, for an ECN-capable TCP connection.  This
> document supplements RFC 2481 [RFC2481], which did not address the
> issue of retransmitted data packets.  This document recommends that
> for ECN-capable TCP implementations, the ECT bit (ECN-Capable
> Transport) in the IP header SHOULD NOT be set on retransmitted data
> packets, and that the TCP data receiver SHOULD ignore the ECN field
> on arriving data packets that are outside of the receiver's current
> window.  This is for greater security against denial-of-service
> attacks.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-ecn-00.txt
>
> 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-tcp-ecn-00.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
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE /internet-drafts/draft-ietf-tsvwg-tcp-ecn-00.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> --NextPart
> Content-Type: Multipart/Alternative; Boundary="OtherAccess"
>
> --OtherAccess
> Content-Type: Message/External-body;
>         access-type="mail-server";
>         server="[email-masked]"
>
> Content-Type: text/plain
> Content-ID:     <[email-masked]>
>
> ENCODING mime
> FILE /internet-drafts/draft-ietf-tsvwg-tcp-ecn-00.txt
>
> --OtherAccess
> Content-Type: Message/External-body;
>         name="draft-ietf-tsvwg-tcp-ecn-00.txt";
>         site="ftp.ietf.org";
>         access-type="anon-ftp";
>         directory="internet-drafts"
>
> Content-Type: text/plain
> Content-ID:     <[email-masked]>
>
> --OtherAccess--
>
> --NextPart--
>
> --__--__--
>
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg
>
> End of tsvwg Digest

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: venkat venkatsubra <[email-masked]>
Date: Sat, 11 Nov 2000 17:24:42 -0600

> Message: 1
> Date: Fri, 10 Nov 2000 11:27:50 -0600
> From: venkat venkatsubra <[email-masked]>
> Organization: IBM
> To: [email-masked]
> Subject: [Tsvwg] Re:ECN draft question
>

Actually i meant i wanted a clarification ;-).

> Fast Retransmit or Retransmit Timeout ?

Ignore my last sentence above.
My question is why would it not have resulted in
any further reduction ?
I am including the relevant statement from rfc2481:

   However, if any retransmitted packets are dropped or have^M
   the CE bit set, then this is interpreted by the source TCP as a new^M
   instance of congestion.

Thanks!
Venkat