RE: Optical Link Interface

Title: RE: Optical Link Interface

Spencer,

I don't really want to get involved in this monotanous debate. However, to answer your question below, yes, all traffic being passed will be painted with the same brush wrt sequenced delivery, even if the order of delivery of some of this data is not important. Alarms/notifications fall very much into the "I do care" category. The degree to which misdelivery of other types of application messages fall into the "I do care" category totally depends on the application protocol - without being familiar with the OLI or the proposed LMP-WDM/NTIP message sets, I cannot comment on the %age of messages conveyed within a typical OLI session for which ordered delivery will be important.

TCP also has another benefit, however, which seems to have been overlooked, and that is end-to-end flow control. I'll let the LMP-WDM/NTIP respective propenents lay down their flow control mechanisms, or otherwise specify why they think it is not required.

Ewart

-----Original Message-----
From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com]
Sent: Thursday, August 02, 2001 1:16 PM
To: '''ccamp@ops.ietf.org' ' '
Subject: RE: Optical Link Interface

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

-----Original Message-----
From: Vasant Sahay [mailto:vasants@nortelnetworks.com]
Sent: Wednesday, August 01, 2001 5:15 PM
To: Dawkins, Spencer; '''ccamp@ops.ietf.org' ' '
Subject: RE: Optical Link Interface

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

-----Original Message-----
From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com]
Sent: Tuesday, July 31, 2001 2:17 PM
To: '''ccamp@ops.ietf.org' ' '
Subject: RE: Optical Link Interface

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!

If you guys were flogging SCTP, I would still be confused, but at least I would think that you weren't ignoring decades of wailing about using TCP for real-time signaling. http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-142.html#TopOfPage is an interesting overview, but doesn't BEGIN to reflect the volume level.

Thanks for any insights you can provide.

Spencer