lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 28 Mar 2012 11:49:43 +0800 From: Chao Pei <peichao85@...il.com> To: Li Yu <raise.sail@...il.com> Cc: netdev@...r.kernel.org Subject: Re: a F-RTO question > Hi, > > I have a question about tcp_process_frto(), the below source > code : > > static int tcp_process_frto(struct sock *sk, int flag) > { > ..... > > if (!before(tp->snd_una, tp->frto_highmark)) { > tcp_enter_frto_loss(sk, ...); > return 1; > } > > ..... > > } > > As my understanding, the tp->frto_highmark likes tp->high_seq, > it saves the seqno SND_NXT when a TCP connection enters F-RTO phase, > is it the variable "recovery" in NewReno? So I think that if snd_una is > equal with or after frto_highmark, which means peer ack new data, so > why we enter Loss state here? > > Thanks! > > Yu > > If snd_una advances to frto_highmark, it is likely that the hole was filled by the retransimitted packet, which means the original packet was likely to have been lost. So, we should enter loss state. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists