Subject: RE: Minutes / Notes

From: "Tony Li" <[email-masked]>
Date: Fri, 18 Jul 2003 10:24:08 -0700

Harold,

The problem is that we get to pick one.  We're making a fundamental
change to the way the Internet works here.  There can't be two
different architectures...

Tony

|    -----Original Message-----
|    From: Grovesteen, Harold [mailto:[email-masked]] 
|    Sent: Friday, July 18, 2003 9:03 AM
|    To: Brian E Carpenter; Tony Li
|    Cc: [email-masked]
|    Subject: RE: Minutes / Notes
|    
|    
|    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:[email-masked]]
|    Sent: Friday, July 18, 2003 3:25 AM
|    To: Tony Li
|    Cc: [email-masked]
|    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:[email-masked]]
|    > |    Sent: Friday, July 18, 2003 12:58 AM
|    > |    To: [email-masked]
|    > |    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:[email-masked]]
|    > |    > Sent: Thursday, July 17, 2003 12:38 PM
|    > |    > To: J. Noel Chiappa; [email-masked]
|    > |    > 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
|    
|

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 19 Jul 2003 17:26:13 +0200

> different architectures...

Now obviously if we're going to substantially change the way the 
internet works to accomodate multihoming, it is inconceivable that we 
leave out maintaining TCP connections through rehoming events.

On the other hand, if we can do multihoming _without_ substantial 
changes but this means breaking TCP sessions whenever a rehoming event 
occurs, that _could_ be a legitimate tradeoff.

But we haven't reached the point where we can make an informed decision 
on this yet. But my personal opinion on the matter is that "substantial 
change" is a red herring. The real question is how hard it is to 
implement a solution. The substantialness or fundamentalness of the 
change has little bearing on the implementation difficulty. The 
adoption of a round earth vs flat earth view is very fundamental but it 
doesn't change the way you navigate a sailboat through the 
Mediterranean Sea very much.

Iljitsch

---

From: Michael Richardson <[email-masked]>
Date: Sun, 20 Jul 2003 13:52:26 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Iljitsch" == Iljitsch van Beijnum <[email-masked]> writes:
    Iljitsch> On the other hand, if we can do multihoming _without_
    Iljitsch> substantial changes but this means breaking TCP sessions
    Iljitsch> whenever a rehoming event occurs, that _could_ be a legitimate
    Iljitsch> tradeoff. 

  My opinion is that there are some additional provisos that will show up
that permit people who care to do something to make the session survive. One
of those will be SCTP, but there may be other things. As such, the "cost"
of that tradeoff may be reduceable to those willing to make minor
investments. 

    Iljitsch> change" is a red herring. The real question is how hard it is to 
    Iljitsch> implement a solution. The substantialness or fundamentalness of
    Iljitsch> the change has little bearing on the implementation
    Iljitsch> difficulty. The adoption of a round earth vs flat earth view is
    Iljitsch> very fundamental but it  
    Iljitsch> doesn't change the way you navigate a sailboat through the 
    Iljitsch> Mediterranean Sea very much.

  I agree.
  Any change to an end system is substantial. As such, a change is a change
is a change.

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Jul 2003 13:29:42 -0400

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

] But my personal opinion on the matter is that "substantial 
] change" is a red herring. The real question is how hard it is to 
] implement a solution. The substantialness or fundamentalness of the 
] change has little bearing on the implementation difficulty. 

if by "how hard it is to implement a solution" you include the effort required
to identify and upgrade all existing software that depends on existing
behavior, and if you also consider the additional effort required to implement
and deploy any future software that needs long-lived sessions, I might agree
with you.  

but we must not fall into the trap of saying "here, I rewrote the kernel code
to do this, and it was easy, threfore the solution is easy to implement".