Re: SCSI over IP (fwd)

[Dave_Lee]

Jon -

Keep in mind that there is no standards track document - the document you have
is merely a proposal by one set of parties.  This effort is pre-WG (chairs,
charters, and final approvals are not complete to my knowledge).  There are a
number of parties that would like to see a proposed standard in the shortest
amount of time but it is a large area.  Thus, it's too early to speculate on
products (standards compatible products, at any rate) but I'd imagine that it'd
be *at least* towards 1Q 2001before we get to proposed standard.

Only one IP networking vendor (Cisco) that I'm aware of has made any public
direction statements in this area, though there is certainly interest among
others - more IP traffic is good for business, after all.  Obviously, the
storage networking industry is interested as well.

Dave




"Jon William Toigo" <[EMAIL PROTECTED]> on 04/26/2000 08:33:18 AM

Sent by:  "Jon William Toigo" <[EMAIL PROTECTED]>


To:   Dave Lee/HQ/3Com
cc:   [EMAIL PROTECTED]
Subject:  Re: SCSI over IP (fwd)




Thanks for the referral, Dave.  Now that I have the SCSI over IP RFC text, I
am wondering how soon, if ever, we will likely see a standard and/or product
based on the specification?

To your knowledge, is SCSI over IP being pursued in earnest by IP networking
equipment companies at present?

JWT

Re: draft-ietf-nat-protocol-complications-02.txt

[J. Noel Chiappa]

> From: Keith Moore <[EMAIL PROTECTED]>

>> You appear to be saying that because historically people screwed up
>> configuring their DNS that it is impossible to rely on the DNS for
>> critical infrastructure.

> I wouldn't say 'impossible'. My point is that it is more difficult to
> get this to work well than it might seem at first glance. ... and note
> that even if you fix the reliability problems associated with using DNS
> to do mapping from global endpoint IDs to local routing information,
> you still have the performance problems to deal with.

Are you making the assumption that we can grow the network in size (let's not
even get into functionality) *without* adding extra architecture/mechanism?

In other words, is your problem with DNS as currently designed/implemented/
maintained - or is it more (as I seem to recall from previous messages from
you) with the general notion that more complex things are fundamentally bad
(since any extra mechanism is also a place for something to go wrong, or a
place to incur overhead)?

If so, I'd say that's false economy - to paraphrase Lincoln on leg length, a
network of a certain size and functionality neeeds a certain amount of
complexity, and if you fail to architect it in (i.e. cleanly), it will get
added around the edges in all sorts of ugly warts (i.e. the kind the Internet
stack is currently infested with).

Noel

RE: draft-ietf-nat-protocol-complications-02.txt

[Vernon Schryver]

> From: "BookIII, Robert" <[EMAIL PROTECTED]>

> ...
> save for a couple of auto-responses from NTMail in the name of
> ...

> but have started up again. Does anyone know how I could go about addressing
> this? Thanks for your time and consideration.

You can expect at least 3 and usually several more "vacation" notices,
delayed delivery warnings, and non-delivery bounces for each message you
send to the main IETF list over the course the week or 10 days after
sending.

By my recollections, even 10 years ago such garbage was unusual and
cause for complaints and apologies.  That nothing happens today, not even
the automatic removal of persistently broken addresses, is a commentary
on the changing nature of the IETF.  If you're an optimist, you might
infer only something about growth.

I've thought of suggesting that the IESG should maintain an address to
which such bounces could be sent to remove the offending address, but
then I've also throught of the reasonable (e.g. authentication) and silly
(e.g. censorship) controveries such a suggestion would trigger.


I've also thought of mentioning that I really don't need to see a dozen
announcements for the same junket of some other organization's boondoogle,
but then I've remembered we've gone through that many times.


Vernon Schryver[EMAIL PROTECTED]

RE: draft-ietf-nat-protocol-complications-02.txt

[BookIII, Robert]

This may be a divergence from the topic, so I'll apologize in advance, but
Vernon's point about bounced emails struck a cord with me. I made the
mistake of leaving a couple of options on my MS Outlook which causes a
receipt to be sent back to me when an email is delivered and when it's read.
At this point, the flurry has calmed down from my first email to the list,
save for a couple of auto-responses from NTMail in the name of
[EMAIL PROTECTED]  . I've been getting
repetitive delivery and read acknowledgements, which seemed to have abated
but have started up again. Does anyone know how I could go about addressing
this? Thanks for your time and consideration.

-Original Message-
From:   Vernon Schryver [mailto:[EMAIL PROTECTED]]
Sent:   Wednesday, April 26, 2000 10:56 PM
To: [EMAIL PROTECTED]
Subject:Re:
draft-ietf-nat-protocol-complications-02.txt

> From: "Steven M. Bellovin" <[EMAIL PROTECTED]>

> ...
> There is some data indicating that Keith is right, that
there are problems in 
> the DNS.  See, for example,
http://www.research.att.com/~edith/Papers/infocom2000.ps

I don't think I understand the connection between that paper
about
"Prefetching the Means for Dcoument Transfer: A New Approach
for Reducing
Web Latency" and Keith's statement that DNS email errors are
usually on
the receiver's side:

] (email errors are usually detected by the sender of a
message, since
] that's who gets the bounced message.  but the party who
has responsibility 
] for fixing the error is usually not on the sender's end of
things)

My perhaps irrelevant, boring, or even wrong claim was that
I'm seeing
more sender-side than receiver-side SMTP+DNS problems.

If the relevance of that paper is that people are have fun
and
games with DNS to help HTTP, and that causes DNS errors that
in
turn cause DNS problems seen by HTTP clients, then that's
consistent
with my personal experience and my claim.  I see many crazy
DNS failures in my personal web surfing.  (crazy either
because
obviously silly for a very big, presumably competently run
site
or because temporary, which says either roots are hosed or
the same
very big, presumably competent site is crazy...have I
mentioned
lately how frequently Akamai is not working for me?)


I bet that the types and frequencies of DNS errors varies
with the
application, which strikes me as a significant change from
how things used
to be.  For example, how many SMTP servers are behind DNS
names that do
fancy load balancing?--yes, I think I can name a very few,
but isn't the
vast majority of SMTP load balancing and so forth based on
turning off
the listen socket (e.g. sendmail), MX records, and non-fancy
round-robin
RR serving?  On the extreme, every venture capital fund
seems to still be
shoveling money at anyone who wants to try anything you'd
care to mention
(and lots more besides) to make HTTP go faster, and many of
those schemes
seem to involve DNS creativity.


Vernon Schryver[EMAIL PROTECTED]

RE: runumbering (was: Re: IPv6: Past mistakes repeated?)

[Evstiounin, Mikhail]

> From: Masataka Ohta [SMTP:[EMAIL PROTECTED]]
> "good *if* and only if"?
> 
> With cookies, a network is as secure as a telephone or fax network, which
> is *GOOD* enough for credit card companies.

Not exactly. It's pretty easy to intercept any packet on the Internet,
that's not
the case for regular phones. Nevertheless, I've read some warnings from
credit companies about not using wireless phones because of security
concerns. Especially, if you live in a crowded area.
... 
>   Masataka Ohta

Re: runumbering (was: Re: IPv6: Past mistakes repeated?)

[Randall Stewart]

Ok,

I will stop being a lurker and chime in since our draft was
mentioned :->

Stephen Sprunk wrote:
> 
> draft-xie-stewart-sigtran-ddp-00 addresses redundancy and failover of
> sessions within a server pool, where uncoordinated failover of sessions from
> one endpoint to another is a requirement.  There is signifcant overheard and
> indirection added to the session to achieve this.
> 
Yes, I think you sum up what DDP attempts to do but I strongly
disagree with your "signifcant overhead" argument. Qiaobing and I
have been playing with DDP now for quite a number of years. It has
some overhead on the wire (not much) since the overhead is mainly
upfront i.e. when you want to go hold a talk to someone you
may need to do a query to find out where it is and where all
its redundant pools are. This drops in to a cache in any sensible
implementation and then within some period will need to expire
or be updated. Even when the cache is updated it does NOT interfere
with the ongoing communication (its done in parrallel). So basically
the delay overhead to talk to a peer is possibly one round trip to
the local ENRP server (of course local is not necessarrily on the
machine you are on but it could be :-0). In some cases there may
be no delay. In particular, the ability to send to a address (pre-known)
and then do a parrallel query to the ENRP deamon. We did not
get this one in the draft but I am sure future updates will have
this ...

The point is I can't see what your "signifcant overhead" is. Yes
it will take a query to get some redundancy but after 5 years of
work I think we have the overhead as slim as we can... of course
perhaps the working group will show us a way to reduce it further
but we will see

> We seem to be discussing a simpler requirement: coordinated movement of a
> session from one ip:port pair on a single endpoint to a different ip:port
> pair on the same endpoint.  Windows, buffer states, sequence numbers, etc.
> could all remain the same.

In its basic state this is what DDP does do.. i.e. if you don't have
multiple peers. But of course if the route fails between you and
your peer, the conversations over.. until the path is back up.

> 
> I would think the latter requirement could be implemented as a simple TCP
> "forward me" option.  For ESP/AH-protected sessions, no TCP-level
> anti-hijacking protection seems necessary.  This could even be performed if
> the original IP is suddenly not available and the other endpoint hasn't
> given up on the connection yet; you send a "forward me" packet sourced from
> the first IP, then listen for an ACK on the new IP.
> 
> I can think of no simple way (ie. without recreating IKE&AH inside TCP) to
> do this for unprotected sessions; I'm not sure it's worth the effort to
> solve either.
> 
> I'm sure there's something I'm missing here, or else this would have been
> implemented 15 years ago...  Thoughts?

Yes, having worked at solving this problem for 5 years you are missing
some of the subtle nature of where the different state is. You really
must have a seperate state around, unless the "new IP" is attached to
the same machine. In that case you end up with something that looks
like SCTP to provide the redundancy, i.e. use the "new IP" address.

R


> 
> S
> 
>  |  | Stephen Sprunk, K5SSS, CCIE #3723
> :|::|:Network Consulting Engineer, NSA
>:|||:  :|||:   14875 Landmark Blvd #400; Dallas, TX
> .:|||:..:|||:.Email: [EMAIL PROTECTED]
> 
> - Original Message -
> From: [EMAIL PROTECTED]
> To: Karl Auerbach
> Cc: IETF
> Sent: Wednesday, April 26, 2000 16:48
> Subject: RE: runumbering (was: Re: IPv6: Past mistakes repeated?)
> 
> > > Turn it any way you want, TCP sessions can only survive renumbering
> through
> > > end to end mechanisms...
> 
> > Which raises the interesting (to me anyway) question: Is there value in
> > considering a new protocol, layered on top of TCP, but beneath new
> > applications, that provides an "association" the life of which transcends
> > the TCP transports upon which it is constructed?
> 
> > I believe that if we had such a protocol that it would be a useful tool to
> > solve many of the juggling acts that transpire under the heading of
> > "mobile networking" as well as providing a way to continue (or
> > "resume") connectivity after IP address changes.
> 
> > (I will, of course, be suitably embarrassed if someone points out that
> > work is already going on to do this.)
> 
>   draft-xie-stewart-sigtran-ddp-00.txt
> 
> ned

-- 
Randall R. Stewart
Member Technical Staff
Network Architecture and Technology (NAT)
847-632-7438 fax:847-632-6733

Re: draft-ietf-nat-protocol-complications-02.txt

[Jon Crowcroft]

In message <[EMAIL PROTECTED]>, "J. Noel Chiappa" typed:

 >>> right, noels wrong.
 
 >>Noel is happy to wait, and see who's right. (I've been through this exact
 >>same experience before, with CLNP, so I understand the life-cycle.) So far,
 >>I've been waiting for quite a few years with IPv6, and so far I'm right.

 >>Let's see, how many years have these standards been out, and how much
 >>deployment has there been? Hmm, RFC-1883 was in December 1995. Can you point
 >>me to *any* other IETF product that, 5 years after the Proposed Standard came
 >>out, still hadn't been significantly deployed - and then went on to be a
 >>success?

 >>No?

wrong - multicast.

 >>I didn't think so.
 
read again  - LOTS of things have seen almost no deployment since
being standar,d and lots of things haev seen deploymewnt (e.g. napster
hit around 15% of college traffic) without even a breath of an i-d
 
 >>> NATs are not only bad e2e karma, they are bad tech

 >>I'm not denying that - and I've said as much. All address-sharing devices are
 >>problematic, and some (e.g. NAT boxes) are downright disgusting kludges.
 >>
 >>However, history shows that bad tech doesn't magically replace itself, it has
 >>to be replaced by an economically viable alternative. (For an example of this
 >>principle in action, note that the vast majority of cars are still powered by
 >>reciprocating internal-combustion engines... talk about poor basic concept!
 >>But I digress)

i agree...

 >>Judging from the real world out there, it appears that IPv6 isn't a viable
 >>alternative.

i agree its not worth holding one's breath...

 cheers

   jon