Subject: [Dime] Retransmit behaviour

From: Ivan Skytte Jørgensen <[email-masked]>
Date: Tue, 18 Jan 2011 01:01:55 +0100

Hi list,

I recently encountered a retransmit behaviour I hadn't seen before. In 
a simple setup with a client directly connected to a server I saw:

1: The client had an internal timer that triggered retransmit of 
message if it had not received a response within a (configurable) 
time limit. The retransmit did not take into account if there had 
been a link failure and retransmitted no matter what.

2: The client did properly set the T-bit in the header and retained 
the end-to-end-identifier as it should, but it also retained the 
hop-by-hop-identifier.

Q1: Can a client set the T-bit even if there has been no link failure?

Q2: If yes, must the hop-by-hop-identifier be retained or must a new 
one be used?

Q3: What is the correct behaviour of an agent or server if it detects 
that the hop-by-hop-identifier is not unique?

Regards,
  Ivan

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 18 Jan 2011 09:59:48 +0900

Hello,

Just a clarifying question: is the client retransmission timer shorter
than TwTimer (watchdog frequency) ?

It looks to me that the client retransmitting the message is useless in
any case, and can only lead to overloading the server. I would like to
hear in which situation this retransmission can be useful, if any.

Best regards,
Sebastien.

Le 18/01/2011 09:01, Ivan Skytte Jørgensen a écrit :
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: Ivan Skytte Jørgensen <[email-masked]>
Date: Tue, 18 Jan 2011 02:36:28 +0100

The client retransmit timer was 1 second by default. The watchdog 
interval was 30 seconds.

On Tuesday 18 January 2011 01:59:48 Sebastien Decugis wrote:
> Hello,
>
> Just a clarifying question: is the client retransmission timer
> shorter than TwTimer (watchdog frequency) ?
>
> It looks to me that the client retransmitting the message is
> useless in any case, and can only lead to overloading the server. I
> would like to hear in which situation this retransmission can be
> useful, if any.
>
> Best regards,
> Sebastien.
>
> > I recently encountered a retransmit behaviour I hadn't seen
> > before. In a simple setup with a client directly connected to a
> > server I saw:
> >
> > 2: The client did properly set the T-bit in the header and
> > retained the end-to-end-identifier as it should, but it also
> > retained the hop-by-hop-identifier.
> >
> > Q2: If yes, must the hop-by-hop-identifier be retained or must a
> > new one be used?
> >
> > Q3: What is the correct behaviour of an agent or server if it
> > detects that the hop-by-hop-identifier is not unique?
> >
> > Regards,
> >   Ivan

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 18 Jan 2011 10:45:18 +0900

Thank you for your answer.

I still fail to see the value of this retransmission behavior, since the
transport layer already cares for transmission loss. At the Diameter
layer, if the server is taking more than 1 second to answer, it probably
means it is busy, there is no value in adding to its load. If the query
was dropped without answer for some reason, the retransmitted message
will very likely have the same treatment.

I would just remove this retransmission mechanism, or if not possible
set the timer to several times TwTimer...

This is only my opinion, other people from the group probably have a
different one :)
Sebastien.

---

From: Ivan Skytte Jørgensen <[email-masked]>
Date: Wed, 19 Jan 2011 00:31:47 +0100

I agree that the blind retransmits have little value and can even be 
harmful. I was also trying to guess why the client had implemented it 
because it had always been obvious to me that server/proxy/relay must 
respond to all requests so there is no point in retransmitting a 
request unless there has been a transport connection failure. But 
when I re-read through rfc3588 again to find chapter&verse to quote I 
realized that it isn't clearly written in section 5.5.4 "Failover and 
Failback Procedures", so I guess that there could exist 
proxies/relays that discard pending requests if the upward transport 
connection breaks, and servers that discard requests for unknown 
reason.

Is it too late to get such clarifications into rfc3588bis ?

Regards,
  Ivan

On Tuesday 18 January 2011 02:45:18 Sebastien Decugis wrote:
> I still fail to see the value of this retransmission behavior,
> since the transport layer already cares for transmission loss. At
> the Diameter layer, if the server is taking more than 1 second to
> answer, it probably means it is busy, there is no value in adding
> to its load. If the query was dropped without answer for some
> reason, the retransmitted message will very likely have the same
> treatment.
>
> I would just remove this retransmission mechanism, or if not
> possible set the timer to several times TwTimer...
>
> This is only my opinion, other people from the group probably have
> a different one :)
> Sebastien.
>
> >> useless in any case, and can only lead to overloading the
> >> server. I would like to hear in which situation this
> >> retransmission can be useful, if any.
> >>
> >> Best regards,
> >> Sebastien.
> >>
> >>> 1: The client had an internal timer that triggered retransmit
> >>> of message if it had not received a response within a
> >>> (configurable) time limit. The retransmit did not take into
> >>> account if there had been a link failure and retransmitted no
> >>> matter what.
> >>>
> >>> Q2: If yes, must the hop-by-hop-identifier be retained or must
> >>> a new one be used?
> >>>