RTOmax in ns3

[El Kinani Youssef]

Hi everyone,

Is there any way to change the value of RTO max in ns3 from 60s to another value ?

Thanks in advance

[Tommaso Pecorella]

Sorry... what ?

There's no upper bound to the RTO as far as I know.

T.

[El Kinani Youssef]

Hi Tomasso,

I think that in linux The function tcp_set_rto() makes sure that RTO isn't larger than TCP_RTO_MAX, which is set to 120 seconds. Is it different in ns3 ? Because also in ns3 I see that the RTO value is freezed in 60s, or its just the number of retries ???

Thanks in advance

--
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/sJBRl0ukDss/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

[Tommaso Pecorella]

Should I check the code for you ?

T.

[El Kinani Youssef]

Hi,

Yes please It would be nice hhhh.I really checked it and found in tcp-socket-base that "m_rto = Min ( doubledRTO, Time::FromDouble (60, Time::S) )", and big thanks for your efforts, and also for your funny and sharp answers.

I want also to know from you if there is a way to detect that a host is unreachable in ns3?

Cheers

[El Kinani Youssef]

Hello,

For my last question, technically is it possible to add a function in "tcp-base-socket.cc" to ping a host callback the reply to trigger some events in tcp?

Thanks

[Nat P]

Il giorno mercoledì 3 giugno 2015 18:20:55 UTC+2, El Kinani Youssef ha scritto:

Hello,

For my last question, technically is it possible to add a function in "tcp-base-socket.cc" to ping a host callback the reply to trigger some events in tcp?

Technically, everything is possible. The right question is: do you really want that?

Nat

[El Kinani Youssef]

Hi guys,

I'm doing some research on TCP behavior over wireless links, one of the problems I'm studying is the Long Connextion DISRUPTION (LCD). As you know TCP is waiting for a RTO before any retransmission. In case of a link disconnection, especially long ones (10s, 20s or that can reach minutes) we have a scenario like in the picture, where TCP is waiting like a fool for the RTO that can reach 60s or 120s in linux). I'm trying to apply sender only modifications, and the idea is to make the transport layer aware of such disconnections. I read a research paper about TCP-LCD that uses ICMP Unreachable Destination message to stop the RTO inflation, in LCD cases. I was thinking about the ping, but ICMP seems better with the Host and Network Unreachable

So what do you think, and is there any other solution to handle this ??

--

[Nat P]

Il giorno giovedì 4 giugno 2015 11:40:07 UTC+2, El Kinani Youssef ha scritto:

Hi guys,

I'm doing some research on TCP behavior over wireless links, one of the problems I'm studying is the Long Connextion DISRUPTION (LCD). As you know TCP is waiting for a RTO before any retransmission. In case of a link disconnection, especially long ones (10s, 20s or that can reach minutes) we have a scenario like in the picture, where TCP is waiting like a fool for the RTO that can reach 60s or 120s in linux). I'm trying to apply sender only modifications, and the idea is to make the transport layer aware of such disconnections. I read a research paper about TCP-LCD that uses ICMP Unreachable Destination message to stop the RTO inflation, in LCD cases. I was thinking about the ping, but ICMP seems better with the Host and Network Unreachable

So what do you think, and is there any other solution to handle this ??

:) I'm not doing this research for you, but I wonder.. how many times you send down your ping packet (which can have, as response, Host Unreachable) to see if the destination is up ?  One per 500ms? One per 1s? Surely, you'll end up sending this ping packet with an exponential backoff solution (like, 30 years of backoff and nobody has invented something better: send one now, wait 200ms, send another, wait 400ms, send another, wait 800ms... and so on). So you'll end up to have something like the RTO but for ping packets. You're moving the RTO problem one layer down, without resolving it.

Have the paper you talked about addressed this? I hope so.

If the RTO goes up to 60s with a "blackout" time of 3-4 seconds, the problem isn't the RTO theory, but the implementation.

Nat
Nat

[Tommaso Pecorella]

Hi,

like Nat, I can't help you much (it's your research).

However... ping *is* ICMP. Moreover, there are a handful of RFCs about neighbor unreachability detection mechanisms, I'd suggest to check them, just search on the IETF archives.

Cheers,

T.

[El Kinani Youssef]

Hi guys,

I really appreciate your answers. You're right Nat, but I don't really want to know if the link is established, what I need is that TCP distinguich betwen congestion and link long disconnection by a limited number of ICMP messages that can tell if the host is unreachable or not (can be 1), to stop the RTO increase (for example to set a variable RTO_MAX of 10 seconds, to reduce the idle time after link reestablishment)? BTW the authors of the paper I mentionned didn't say how to trigger ICMPs (they knew what they will have to deal with), they gave an approach on how to use them. And thank you Tomasso for the clue, I'll do that.

I will try to do what I have in mind, and In case of I'm stuck in something "I will look for you, I will find you, and I will ask your help" :)

Big thanks
 

[El Kinani Youssef]

hi,

Just to let you Know TCP-LCD extension is available linux version (>=2.6.32), and it seems that it earlier detects a restored connectivity, I'll understand how this works and try to add this to ns3 tcp.

Cheers

[Tommaso Pecorella]

Hi,

let us know your findings, and if you have a patch, we'll be happy to review the code to include it in future ns-3 releases.

As a side note, TCP doesn't really react to ICMP messages. It could (and it should), but it doesn't. E.g., ICMP too big should be used to tweak the TCP segment size and to not trigger a  retransmission due to congestion, etc.

Perhaps this part should be expanded and could suit your needs.

Cheers,

T.