Subject: [tcpm] My time slot, TCP spurious loss detection with nonces

From: Michael Welzl <[email-masked]>
Date: Wed, 30 Mar 2011 14:52:52 +0200

Hi,

It's getting clear that I won't get the time to present at today's  
meeting; my item on the agenda is listed as tentative, as I also told  
the chairs that I don't care if they kick me out, I see this as a low- 
priority item.

Anyway: the point of the presentation would have been to repeat the  
question I raised before on the list:
http://www.ietf.org/mail-archive/web/tcpm/current/msg06380.html

For more info: the chairs uploaded my slides:
http://www.ietf.org/proceedings/80/slides/tcpm-2.pdf
and there's more stuff at http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html

I'd just like to get an idea of whether someone cares about this, i.e.  
whether it's worth continuing, given the shaky ground underneath the  
ECN nonce.
If I don't see any significant interest from the list soon now, it  
just goes in the dump. No worries though  :-)

Cheers,
Michael

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 31 Mar 2011 09:39:25 +0200

AFAICT, the detection happens one RTT after the spurious retransmit like
DSACK?

It's a cute idea but since DSACK is on by default in poplar stacks, it may
not be that useful?

On Wed, Mar 30, 2011 at 2:52 PM, Michael Welzl <[email-masked]> wrote:

> Hi,
>
> It's getting clear that I won't get the time to present at today's meeting;
> my item on the agenda is listed as tentative, as I also told the chairs that
> I don't care if they kick me out, I see this as a low-priority item.
>
> and there's more stuff at
> http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html
>
> whether it's worth continuing, given the shaky ground underneath the ECN
> nonce.
> If I don't see any significant interest from the list soon now, it just
> goes in the dump. No worries though  :-)
>
> Cheers,
> Michael
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Michael Welzl <[email-masked]>
Date: Thu, 31 Mar 2011 10:01:58 +0200

no, it doesn't.

here's an example. you send, say, 10 packets, and run into RTO, and  
retransmit them all. if you then get, say, acks for packets 1-3 whose  
nonce sums match the nonces of the originally transmitted packets, you  
can react. the ack carrying DSACK may still be in flight at this  
point. in fact, even the retransmitted data packets that would  
potentially cause a DSACK to be sent would still be in flight.

this is illustrated with simulations in the globecom paper and the  
master thesis at http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html

my question really is about the group's view of the ECN nonce... my  
idea just adds a bit more value to it, the way i see it - but AFAIK  
noone uses the nonce... so what?

cheers
michael

On Mar 31, 2011, at 9:39 AM, Yuchung Cheng wrote:

> AFAICT, the detection happens one RTT after the spurious retransmit  
> like DSACK?
>
> It's a cute idea but since DSACK is on by default in poplar stacks,  
> it may not be that useful?
>
> meeting; my item on the agenda is listed as tentative, as I also  
> told the chairs that I don't care if they kick me out, I see this as  
> a low-priority item.
>
> I'd just like to get an idea of whether someone cares about this,  
> i.e. whether it's worth continuing, given the shaky ground  
> underneath the ECN nonce.

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 31 Mar 2011 09:36:34 +0100

Yuchung,

DSACK feedback can only be sent out, once the receiver has seen these additional segments. Same problem with F-RTO - detection is delayed. 

If the original segments carry *SOME* unique tag that would disambiguate them from the retransmitted ones, this feedback is available to the sender about 1 RTT earlier... (while you still remember the TCPCB state prior to the wrong congestion action).

Eifel uses timestamp information (if that's sufficiently granular) for that purpose too - but as discussed, only works if the first retransmissions is subsequently received in-sequence.

Basically, my draft with immediate echoing of the timestamps would provide the same signal (without the added complexity of a probabilistic detection only). The added benefit would be, that the sender can figure this out also when there are reordered ACKs, lost retransmissions etc...

Another scheme could also shift the segment boundaries (length of the data segments) as a signal to disambiguate between original and retransmitted segments. However, such a scheme - while workable without any receiver participation and no requirement of any TCP options - has other issues (ie. Increasing the packet rate = network processing overhead; segment based stacks would also not like that approach I gather). Sending at least one additional segment for each hole of sequence space in the receivers buffer would violate the packet conservation principle as I understand it.

One more comment: RFC3540 (ECN Nonce) doesn't appear to be available in many stacks at all. Conex is also looking into overloading this bit for a better ECN feedback mechanism than what is in RFC3168, that does not mask feedback for one RTT (ECE/CWR exchange)...

Richard Scheffenegger

> -----Original Message-----
> From: Michael Welzl [mailto:[email-masked]]
> Sent: Donnerstag, 31. März 2011 10:02
> To: Yuchung Cheng
> Cc: tcpm
> Subject: Re: [tcpm] My time slot, TCP spurious loss detection with
> nonces
> 
> no, it doesn't.
> 
> master thesis at

---

From: Michael Welzl <[email-masked]>
Date: Thu, 31 Mar 2011 11:00:31 +0200

On Mar 31, 2011, at 10:36 AM, Scheffenegger, Richard wrote:

> Yuchung,
>
> DSACK feedback can only be sent out, once the receiver has seen  
> these additional segments. Same problem with F-RTO - detection is  
> delayed.
>
> If the original segments carry *SOME* unique tag that would  
> disambiguate them from the retransmitted ones, this feedback is  
> available to the sender about 1 RTT earlier... (while you still  
> remember the TCPCB state prior to the wrong congestion action).
>
>
> Eifel uses timestamp information (if that's sufficiently granular)  
> for that purpose too - but as discussed, only works if the first  
> retransmissions is subsequently received in-sequence.
>
>
>
> Basically, my draft with immediate echoing of the timestamps would  
> provide the same signal (without the added complexity of a  
> probabilistic detection only). The added benefit would be, that the  
> sender can figure this out also when there are reordered ACKs, lost  
> retransmissions etc...

I agree, but of course this prompts me to say "...but it needs  
timestamps", and "my scheme is probabilistic, yes, but it's still very  
simple".

> Another scheme could also shift the segment boundaries (length of  
> the data segments) as a signal to disambiguate between original and  
> retransmitted segments. However, such a scheme - while workable  
> without any receiver participation and no requirement of any TCP  
> options - has other issues (ie. Increasing the packet rate = network  
> processing overhead; segment based stacks would also not like that  
> approach I gather). Sending at least one additional segment for each  
> hole of sequence space in the receivers buffer would violate the  
> packet conservation principle as I understand it.

I agree again, but just as a data point, this scheme was actually  
proposed, in:
K. Tan, Q. Zhang, and W. Zhu, “STODER: a robust and efﬁcient  
algorithm for handling spurious retransmit timeouts in  
TCP,”inGLOBECOM’05, vol. 6, no. 2, St. Louis, Missouri, USA,  
December 2005, pp. 3692–3696.

> One more comment: RFC3540 (ECN Nonce) doesn't appear to be available  
> in many stacks at all. Conex is also looking into overloading this  
> bit for a better ECN feedback mechanism than what is in RFC3168,  
> that does not mask feedback for one RTT (ECE/CWR exchange)...

Yes, exactly - these are the issues that made me give up on my plan of  
doing this in any case, and made me ask here if there is even any  
interest on this (i.e. the nonce, in general), or if I'm adding  
decoration to a corpse here...

Cheers,
Michael

---

From: Alexander Zimmermann <[email-masked]>
Date: Thu, 31 Mar 2011 12:34:58 +0200

Hi,

> DSACK feedback can only be sent out, once the receiver has seen these additional segments. Same problem with F-RTO - detection is delayed.

Richard, I don't get this. IMO F-RTO is fast as Eifel regarding the detection time.
It avoids the typical go-back-n recovery.

Alex

> One more comment: RFC3540 (ECN Nonce) doesn't appear to be available in many stacks at all. Conex is also looking into overloading this bit for a better ECN feedback mechanism than what is in RFC31…

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22222
// email: [email-masked]
// web: http://www.umic-mesh.net
//

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 31 Mar 2011 12:52:07 +0100

> It avoids the typical go-back-n recovery.

True, sorry. Of course, the same limitation that applies to Eifel also
applies here (tcp timestamp clock needs to tick once per RTT at least). 

Richard Scheffenegger