Subject: Re: [Tsvwg] Re: HighSpeed TCP for Large Congestion Windows

From: Mark Allman <[email-masked]>
Date: Tue, 17 Sep 2002 23:13:36 -0400

[Clearly I can't keep up very well.  So, sorry for the delayed
 response.] 

> Do you think it could be problematic to recover from a cwnd of
> thousand of packets?  What happen in a scenario (unrealistic?)
> where 1 HighSpeed TCP if filling a pipe of 10Gb/s, 100ms RTT, and
> then a second HS-TCP starts? How many packets are going to be
> lost?  Even if only 1/10 of cwnd packets are going to be lost,
> about 800 packets will be dropped.  Will sack be able to handle
> that? Probably not... and how many RTT will be necessary to
> successfully terminate a Fast (?) Recovery?  

I'm interested in knowing why you think SACK-based recovery will not
work effectively in this case?  I think it should work just fine in
the case when 10% of the packets are lost (regardless of how many
losses that happens to be).

(FYI: My mental model of SACK is draft-allman-tcp-sack-12.txt)

> And what will happen if a RTO expires? How many duplicated
> segments will be carried by the network?  Do you believe that this
> can be an issue?

Hopefully with SACK we will not send needless retransmits into the
network.  Or, at least not that many.

On the other hand, if you end up using Reno we have some recent
measurements that suggest about 1 out of every 3 retransmits is
needless.  So, given Reno's grossness this *might* be an issue with
huge windows.  

allman

--
Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Marco Mellia <[email-masked]>
Date: Mon, 23 Sep 2002 13:56:20 +0200

> [Clearly I can't keep up very well.  So, sorry for the delayed

Me too...

> losses that happens to be).

I'm not an expert in SACK, but if I'm not wrong, there are a couple of issues 
that can limit SACK behaviour:
- no more that 3 SACK block per ACK can be accomodated
- the pipe mechanism will limit the number of retransmission per RTT
- SACK will fall back to RTO in case a retransmitted packet is lost

I was just thinking if 10% of dropped packets (which is equivalent to more 
than 80 dropped packets that have to be recovered) might be an issue.
In particular, which is the probability that a retransmitted packet is not 
dropped?

-- 
Ciao,                    /\/\/\rco

+-----------------------------------+  
| Marco Mellia - Assistant Professor|
| Tel: 39-011-5644173               |
| Cel: 39-340-9674888               |   /"\  .. . . . . . . . . . . . .
| Politecnico di Torino             |   \ /  . ASCII Ribbon Campaign  .
| Corso Duca degli Abruzzi 24       |    X   .- NO HTML/RTF in e-mail .
| Torino - 10129 - Italy            |   / \  .- NO Word docs in e-mail.
| http://www1.tlc.polito.it/mellia  |        .. . . . . . . . . . . . .
+-----------------------------------+
The box said "Requires Windows 95 or Better." So I installed Linux.
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Mark Allman <[email-masked]>
Date: Mon, 23 Sep 2002 08:39:16 -0400

So, lets assume a cwnd of 800 packets and that 80 are lost.

> I'm not an expert in SACK, but if I'm not wrong, there are a
> couple of issues that can limit SACK behaviour:
>

That's right (assuming timestamps, which you'd need for a cwnd of
800 packets (of much size, anyway).  But, we're going to have 720
ACKs to piggyback SACK information on.  And, 80 losses can cause at
most roughly 80 SACK blocks.  So, it seems like there are plenty of
chances for returning all the SACK information to me.

> - the pipe mechanism will limit the number of retransmission per RTT

We will be able to send 400 packets in the RTT following loss
detection.  That is five tims what we lost.  I think that should
suffice to allow for the retransmission of everything.

> - SACK will fall back to RTO in case a retransmitted packet is lost

Not necessarily.  If you look at our current draft
(draft-allman-tcp-sack-12.txt) then yes, if a retransmit is dropped
we will RTO.  And, there is probably a higher chance of losing a
retransmit when the window is larger.  But, you'd have to do the
experiment before I believed this was a huge problem.  And, further,
SACK *can* detect lost retransmits and retransmit again without an
RTO if the TCP sender is willing to keep more state.  I know some
folks have hashed out schemes to do this.

My high order point here is that I do not think there is anything
fundementally wrong with SACK such that it will not work with large
cwnds in a high speed environment.  I believe it scales.

allman

--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg