RE: Minutes / Notes

["Grovesteen, Harold" <Grovesteen@aafes.com>]

Please understand that there is a middle ground between EDI financial based transactions and checking out a recreational web site.  Enterprises which depend upon user's browsing to generate revenue fit in this middle ground.  It may be casual browsing on the part of the customer, but there is nothing casual about the enterprise's approach to reliability to maximize that revenue stream.  When millions of dollars or yen or pounds are at risk, even short disruptions and any broken connections with those casual users represent lost revenue.

I had wanted to stay out of this discussion, but I had not anticipated the results of my simple affirmation that TCP connection survival is a good thing and I representing an Enterprise am glad this is still a "should" and "on the table."  I do not even have any issue that some solutions provide this and others do not.  I can select a solution that does and support my organization as needed--provided it is not incompatible with the other solutions.

Harold Grovesteen

-----Original Message-----
From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
Sent: Friday, July 18, 2003 3:25 AM
To: Tony Li
Cc: multi6@ops.ietf.org
Subject: Re: Minutes / Notes


Tony,

Yes, but you can't use the same argument for casual web browsing.

BTW, this is why commercial message queueing systems exist; they
can bridge reliable transactions over significant disconnects.

   Brian

Tony Li wrote:
> 
> Brian,
> 
> If we do not fix this, then we can just close up shop and go home,
> because the business world is NOT going to accept a solution that
> doesn't fulfill this.  They would rather use IPv4 and PI addresses.
> 
> Tony
> 
> |    -----Original Message-----
> |    From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
> |    Sent: Friday, July 18, 2003 12:58 AM
> |    To: multi6@ops.ietf.org
> |    Subject: Re: Minutes / Notes
> |
> |
> |    Well, this is one of the many "shoulds" in our agreed list
> |    of goals. Whether we can achieve this "should" simultaneously
> |    with enough of the others is very much an open question
> |    in my mind, and it's one of the reasons why we may end up
> |    with more than one solution. In some scenarios, this may
> |    be a dominant goal; in other scenarios, it may be unimportant.
> |
> |      Brian
> |
> |    "Grovesteen, Harold" wrote:
> |    >
> |    > YES!
> |    >
> |    > -----Original Message-----
> |    > From: Tony Li [mailto:Tony.Li@procket.com]
> |    > Sent: Thursday, July 17, 2003 12:38 PM
> |    > To: J. Noel Chiappa; multi6@ops.ietf.org
> |    > Subject: RE: Fwd: Minutes / Notes
> |    >
> |    > Noel,
> |    >
> |    > |    This is only important if you want TCP connections to be
> |    > |    able to survive
> |    > |    having an incoming link fail (i.e. the address on the
> |    > |    local end becomes
> |    > |    unreachable to the rest of the network). This may not be
> |    > |    an important goal
> |    > |    (e.g. the typical web site wouldn't care).
> |    >
> |    > I believe that the WG has come to rough consensus that this is,
> |    > in fact, an important goal for us to solve.  There are
> |    > numerous practical applications that drive this.  More generally,
> |    > we (IETF, vendors) are being asked to make the Internet safe
> |    > for "mission critical" applications and having broken TCP
> |    > connections is simply unacceptable.  Many applications today
> |    > are being outsourced: backups, storage, business applications,
> |    > interactions within an 'extra-net', etc.
> |    >
> |    > Tony