[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Optical Link Interface
Title: RE: Optical Link Interface
Dear
Spencer,
We
have also recommended shortening the retransmit timer and turning Nagle
off.
In-order delivery is a requirement for NTIP/OLI.
As an example, if a DWDM system reports a defect such as SF (SIgnal Fail) for a
port to OXC, the OXC will condider the port failed untill a DC (Defect Clear) is
reported by DWDM. Hence maintaining the order of failure reporting(SF), and
clearing of failure(DC) is critical.
When
we co-authored the requirements for OLI we specified that OLI needs a reliable
transport protocol. We dont want OLI to reinvent a new mechanism for recovering
lost messages. NTIP is designed to use services from an existing reliable
transport protocol. TCP is a reasonable and mature solution so we picked it.
As we go
further, if a better reliable transport protocol is identifed we are open to
adopting it.
However LMP invents that part and the
details are not thought through yet. Also, as you know the round trip delays,
flow control and congestion control in any implementation will have different
implications for WAN and LAN environment. Since LMP is proposed over WAN as
plain LMP and over LAN as WDM-LMP, the recovery scheme will need additional
work on tuning it for the two applications.Reinventing a solution (as in
case of LMP), has additional technical, business and time-to-market issues.
Regards
Vasant
Dear Vasant,
Are there any other TCP optimizations you are
considering?
Another frequent reason given for not using TCP
is that TCP delays delivery of received data while missing data is recovered.
TCP forces in-order delivery, even if there's no dependence on ordering (so,
in this case, does the order alarms are received in really
matter?)...
Spencer
Dear Spencer,
LMP is a WAN protocol hence losses, round trip times and congestion
control are more involved.
NTIP runs in a controlled environment where the OXC and DWDM
are co-located. The
traffic engineering is basic and
simple. Also the platforms are not general purpose OS but embedded
systems with optimized code. Exponential back off can be disabled for
this application.
Please see my
related comments in other ccamp responses as
well.
Vasant
Dear Vasant,
OK, I'll bite.
My copy of TCP/IP Illustrated,
volume 1, shows TCP doing exponential backoff (page 299), at a pretty
leisurely pace, for about nine minutes before giving up. This is, of
course, measured using a general-purpose OS, but at some point - well, how
long were you planning to wait for TCP
retransmissions?
I am somewhat confused as to how this lines
up with successfully retransmitting lost "events" in 10s of
ms.
I am somewhat confused as to how using TCP
(with exponential retransmission timers) is a substitute for
application-level timers. If you have to run application-level timers
anyway... well, I thought that was where SCTP came
from!
Thanks for any insights you can
provide.
Spencer