Re: [ipfix] STCP as a default transport not

["Randall Stewart (cisco)" <[e-mail]>]

Carter:

The paper you site.. and yes I am on it.. was the basis
we used to make sure "newreno" behavior for fast retransmit
was put into the SCTP implementors guide. Now most implementations
already were doing this (at least those I have talked to)...

And as it is I don't think you will find true NewReno behavior
in ALL TCP implementations either :-< So I guess by this
reasoning TCP is also immature :-D

SCTP is a VERY stable protocol that has a LOT of implementations (over 
20 that I
know of... probably close to 30 if I took the time to count them :>). Is 
there more
research to do.. of course there is.. the same can be said for TCP.. 
thats why
the TSVWG exists ..we are always trying to make things better :>

R

Carter Bullard wrote:

>My principal concern is that SCTP is too young to be the only transport.
>For example, a recent Univ. of Delaware Technical Document, co-authored
>by Cisco, identifies a serious problem with SCTP congestion control
>when there are multiple drops in a single window, causing it to degrade
>"more than necessary to be 'TCP-friendly', i.e. it grinds to a dribble
>for a little while, while transmitting more packets.  The link where
>you can get the publication is:
>
>http://www.eecis.udel.edu/~amer/PEL/poc/index.html
>
>The paper is "SCTP and TCP Variants: Congestion Control Under Multiple
>Losses", very recent.  The point is that these are the normal growing
>pains of a new protocol, but SCTP and PR-SCTP still have some problems
>to iron out.
>
>Like Jeff, I have no problems with IPFIX running over PR-SCTP, but
>not as the only protocol.
>
>Carter
>
>
>
>
>  
>
>>-----Original Message-----
>>From: MEYER,JEFFREY D (HP-Cupertino,ex1) [mailto:[e-mail]]
>>Sent: Friday, October 10, 2003 9:46 AM
>>To: 'Benoit Claise'; MEYER,JEFFREY D (HP-Cupertino,ex1)
>>Cc: [e-mail]; [e-mail];
>>[e-mail]; 'Reinaldo Penno';
>>[e-mail]; [e-mail]; [e-mail]
>>Subject: RE: [ipfix] STCP as a default transport not
>>
>>
>>Benoit,
>>
>>  I am not in any way against specifying IPFIX on top of PR-SCTP,
>>what I am against is making that the ONLY supported transport.
>>This is for practical reasons, like availability of implementation.
>>And as cited before because of transport protocols' affinity
>>for running in kernel vs. user space, the availability is going
>>to be a lot slower coming than one might like.
>>
>>  I would liken this to deciding to define a transport layer
>>protocol which could only run on IPv6 and not IPv4.  You could,
>>but if you can run on both, I think there are decided benefits.
>>
>>  The Diameter authors seemed to have made this pragmatic choice.
>>
>>  It is a bit ironic that previous decisions of the WG around
>>choice of candidate protocols were ultimately trumped by "practical
>>reasons" like NF is more widely deployed, despite the fact
>>that it was the only protocol with NO binding to a congestion
>>aware transport.  And now, the arguments seem to be a complete
>>180 change.
>>
>>Regards,
>>
>>  Jeff Meyer
>>
>>    
>>
>>>-----Original Message-----
>>>From: Benoit Claise [mailto:[e-mail]]
>>>Sent: Friday, October 10, 2003 3:26 AM
>>>To: MEYER,JEFFREY D (HP-Cupertino,ex1)
>>>Cc: [e-mail]; [e-mail]; [e-mail];
>>>'Reinaldo Penno'; [e-mail];
>>>[e-mail]; [e-mail]
>>>Subject: Re: [ipfix] STCP as a default transport not
>>>
>>>
>>>Jeff,
>>>
>>>My point is that I'm convinced that SCTP-PR gives all the
>>>      
>>>
>>advantages
>>    
>>
>>>in one transport protocol. See the recent postings from Peter
>>>Lei; he knows the protocol a lot
>>>better than I do!
>>>Having the full flexibility (reliable, unreliable, partially
>>>reliable) in one transport protocol would be a plus.
>>>Let's give the flexibility to the different implementations.
>>>On the top of that, we don't know yet the future applications
>>>of IPFIX:
>>>PSAMP is one, exporting SLA information?, some MIB variables
>>>export?, etc... everything is possible since IPFIX is a generic
>>>export format.
>>>As I said, I think we should just use the right protocol
>>>instead of just
>>>using what exists. IMHO, SCTP_PR should be the target as transport
>>>transport. So, I would vote for SCTP with the PR extension.
>>>
>>>Regards, Benoit.
>>>
>>>
>>>      
>>>
>>>>Benoit,
>>>>
>>>> SCTP-PR does not make me happy, nor do the previous decisions
>>>>around reliability as it regards to billing.
>>>>
>>>> Dropping packets under congestion is already done by UDP, and
>>>>UDP is ubiquitous in all OS's.
>>>>
>>>> Is there some challenge in defining IPFIX over TCP?  It seems
>>>>to me that this is the easier case, there are less things to map
>>>>to vs. SCTP-PR.  Is explicitly NOT defining a mapping to TCP
>>>>your proposal, i.e. force the use of SCTP-PR?
>>>>
>>>> As with the experience of Diameter, specifying both transports
>>>>will enable a migration to SCTP-PR for everyone if it actually
>>>>proves to have the values espoused and it is readily available.
>>>>In the interim having a TCP mapping (and UDP) would address the
>>>>requirements which I've encountered (billing issues aside).
>>>>
>>>> As Peter pointed out the resource constraints on the exporter
>>>>imposed by TCP can be mitigated in the implementation.
>>>>
>>>>Regards,
>>>>
>>>> Jeff Meyer
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>-----Original Message-----
>>>>>From: Benoit Claise [mailto:[e-mail]]
>>>>>Sent: Thursday, October 09, 2003 9:15 AM
>>>>>To: [e-mail]
>>>>>Cc: [e-mail]; [e-mail]; 'Reinaldo Penno';
>>>>>'MEYER,JEFFREY D (HP-Cupertino,ex1)';
>>>>>          
>>>>>
>>>[e-mail];
>>>      
>>>
>>>>>[e-mail]; [e-mail]
>>>>>Subject: Re: [ipfix] STCP as a default transport not
>>>>>
>>>>>
>>>>>Dear all,
>>>>>
>>>>>There are advantages regarding the use of SCTP versus TCP
>>>>>          
>>>>>
>>>(discussed
>>>      
>>>
>>>>>already on the list) but I think that the biggest advantage
>>>>>of SCTP is
>>>>>actually the extension SCTP-PR. And I'm surprised to see no
>>>>>reactions on
>>>>>the email below.
>>>>>Yes, I know that the SCTP-PR is not a standard yet but I
>>>>>think that we
>>>>>should just take the right protocol instead of just using
>>>>>          
>>>>>
>>>what exists
>>>      
>>>
>>>>>because it exists!
>>>>>
>>>>>I remember the heated discussions maybe one year ago about
>>>>>using IPFIX
>>>>>for billing, about high availability, etc...
>>>>>And one of the solution that could make everybody happy
>>>>>          
>>>>>
>>is: SCTP-PR.
>>    
>>
>>>>>We know that we do have some memory issues with TCP on the
>>>>>high-end routers.
>>>>>But, for the smaller exporter OR if you can afford/if it's
>>>>>possible to
>>>>>pack the exporter with the appropriate amount of  memory,
>>>>>SCTP-PR would
>>>>>work perfectly well!
>>>>>Now, in the majority of cases (no billing, no enough
>>>>>          
>>>>>
>>>memory/too many
>>>      
>>>
>>>>>flow records, etc...) SCTP-PR would drop the flow records
>>>>>excess if any,
>>>>>which I think is the right thing to do.
>>>>>
>>>>>Regards, Benoit.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>I think that the interest is in using PR-SCTP as described in
>>>>>>
>>>>>>            
>>>>>>
>>>>>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-prsctp-01.txt
>>>>>          
>>>>>
>>>>>>rather than RFC 2960 SCTP.
>>>>>>
>>>>>>This claims the following benefits:
>>>>>>
>>>>>>
>>>>>>1.3 Benefits of PR-SCTP
>>>>>>
>>>>>>  Hereafter, we use the notation "PR-SCTP" to refer to the SCTP
>>>>>>  protocol extended as defined in this document.
>>>>>>
>>>>>>  The following are some of the advantages for integrating
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>partially
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>  reliable data service into SCTP, i.e., benefits of PR-SCTP:
>>>>>>
>>>>>>  1.  Some application layer protocols may benefit from
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>being able to
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>      use a single SCTP association to carry both reliable
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>content, --
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>      such as text pages, billing and accounting
>>>>>>            
>>>>>>
>>>information, setup
>>>      
>>>
>>>>>>      signaling -- and unreliable content, e.g. state that
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>is highly
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>      sensitive to timeliness, where generating a new
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>packet is more
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>      advantageous than transmitting an old one [1].
>>>>>>
>>>>>>  2.  Partially reliable data traffic carried by PR-SCTP
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>will enjoy the
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>      same communication failure detection and protection
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>capabilities
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>      as the normal reliable SCTP data traffic does. This
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>includes the
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>      ability to: - quickly detect a failed destination
>>>>>>            
>>>>>>
>>address; -
>>    
>>
>>>>>>      fail-over to an alternate destination address, and;
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>- be notified
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>      if the data receiver becomes unreachable.
>>>>>>
>>>>>>  3.  In addition to providing unordered unreliable data
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>transfer as
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>      UDP does, PR-SCTP can provide ordered unreliable
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>data transfer
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>      service.
>>>>>>
>>>>>>  4.  PR-SCTP employs the same congestion control and congestion
>>>>>>      avoidance for all data traffic, whether reliable or
>>>>>>            
>>>>>>
>>>partially
>>>      
>>>
>>>>>>      reliable  - this is very desirable since SCTP enforces
>>>>>>      TCP-friendliness (unlike UDP.)
>>>>>>
>>>>>>  5.  Because of the chunk bundling function of SCTP,
>>>>>>            
>>>>>>
>>reliable and
>>    
>>
>>>>>>      unreliable messages can be multiplexed over a
>>>>>>            
>>>>>>
>>single PR-SCTP
>>    
>>
>>>>>>      association.  Therefore, the number of IP datagrams
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>(and hence
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>      the network overhead) can be reduced versus having
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>to send these
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>      different types of data using separate protocols.
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>Additionally,
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>      this multiplexing allows for port savings versus
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>using different
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>      ports for reliable and unreliable connections.
>>>>>>
>>>>>>----------
>>>>>>
>>>>>>PR-SCTP has the option of being able to configure the
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>exporter to work
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>on a
>>>>>>best effort data export basis, rather than being
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>constrained to work on a
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>reliable basis.
>>>>>>
>>>>>>We should spend some time thinking about the behaviour we
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>want in the
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>exporter when the network is congested, perhaps due to an
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>attack. PR-SCTP
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>gives us the option of running a best effort data
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>collection to gleen
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>what
>>>>>>is going on, when a TCP based exporter would otherwise
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>collapse due to
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>backlog on the exporter.
>>>>>>
>>>>>>Stewart
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>--
>>>>>>Help        mailto:[e-mail] and say "help" in
>>>>>>message body
>>>>>>Unsubscribe mailto:[e-mail] and say
>>>>>>"unsubscribe ipfix" in message body
>>>>>>Archive     http://ipfix.doit.wisc.edu/archive/
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>
>>>>>          
>>>>>
>>>      
>>>
>
>
>
>
>  
>


-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[e-mail] 815-342-5222(cell) or 815-477-2127(office)



--
Help        mailto:[e-mail] and say "help" in message body
Unsubscribe mailto:[e-mail] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/