cox.net mail contact?

[Andrew Prowant]

I hate to do this but I have been unable to get anyone at cox.net to
respond. No answer from postmaster after weeks of trying.

If there is a cox.net contact on the list, I would be extremely grateful if
you could put me in contact with a cox.net mail admin. Email to our
customers is accepted by the cox.net mail servers but our customers claim
the mail never arrives.

Thank you,
Andrew

Re: Verizon and spam reports

[Heather Schiller]

Hank Nussbacher wrote:
I have tried repeatedly by private email directly to Verizon and I have 
contacted an ex-UUnet employee, but so far, it would appear that Verizon 
is running an unattended and unmaintained "spam reporting" system with 
emails like this:


For questions about these reports please email: 
[EMAIL PROTECTED]
NOTE: there is no need to acknowledge these reports, the email 
address: [EMAIL PROTECTED] is purely for questions.


Some frequently asked questions about this process and its fallout can 
be found here: http://www.secsup.org/complaints/


The following spam message was received at Thu, 05 Jun 2008 17:03:01 
+0300


IP: x.x.1.242
TIMESTAMP: Thu, 05 Jun 2008 17:03:01 +0300
 GMT-


Problem is they are basing who to send the spam report on an email 
address that was changed in whois about 2 years ago and it would appear 
no one is home to update their "spam reporting" database.


Is anyone here from Verizon who can reach out to the people sending 
these emails to have them fix their database?


Thanks,
Hank





Yes.. Send me your details (IP/ASN/ORG ID) and I'll have someone update 
the db.


  --Heather

--
~*~*~*~*~*~*~*~*~*~*~*~
 Heather Schiller
 Customer Security
 IP Address Management
 1.800.900.0241
~*~*~*~*~*~*~*~*~*~*~*~

Re: [Outages] outages wiki? feedback please

[Jeff Shultz]

Jay R. Ashworth wrote:

On Wed, Jun 11, 2008 at 09:50:24PM -0700, virendra rode // wrote:

Wiki would serve well for documentation purposes such as operational,
ISP related such as peer relationships, isp contacts, tools, etc., but
nothing comes close to real-time outages (user feedback) via e-mail.


Or, perhaps, an RSS feed from a user-maintained ticketing system.

I've always wanted to build a public ticketing system, where you could,
for example, hang a ticket on a traffic signal that was out...

Cheers,
-- jra



I can think of a few people I know that would report every single 
traffic signal (and maybe a few stop signs) as out within 3 days.


I'm sure they'd be imaginative in their use of names too.

--
Jeff Shultz

Spamhaus down?

[Raymond L. Corbin]

Something going on with SpamHaus site/ dnsbl servers?


spamhaus.org1   SOA
server: need.to.know.only 259200s
email:  [EMAIL PROTECTED]
serial: 2008060901
refresh:3600
retry:  600
expire: 2419200
minimum ttl:3600

spamhaus.org1   TXT v=spf1 ip4:82.94.216.224/27 -all172800s
spamhaus.org1   NS  ns8.spamhaus.org172800s
spamhaus.org1   NS  ns20.ja.net 172800s
spamhaus.org1   NS  hq-ns.oarc.isc.org  172800s
spamhaus.org1   NS  ns2.spamhaus.org172800s
spamhaus.org1   NS  ns3.xs4all.nl   172800s
spamhaus.org1   NS  ns3.spamhaus.org172800s
spamhaus.org1   MX  preference: 10   300s
exchange:   smtp-ext-layer.spamhaus.org

-Ray

Re: [Outages] outages wiki? feedback please

[Jay R. Ashworth]

On Thu, Jun 12, 2008 at 10:53:54AM -0700, Jeff Shultz wrote:
> Jay R. Ashworth wrote:
> >On Wed, Jun 11, 2008 at 09:50:24PM -0700, virendra rode // wrote:
> >>Wiki would serve well for documentation purposes such as operational,
> >>ISP related such as peer relationships, isp contacts, tools, etc., but
> >>nothing comes close to real-time outages (user feedback) via e-mail.
> >
> >Or, perhaps, an RSS feed from a user-maintained ticketing system.
> >
> >I've always wanted to build a public ticketing system, where you could,
> >for example, hang a ticket on a traffic signal that was out...
> 
> I can think of a few people I know that would report every single 
> traffic signal (and maybe a few stop signs) as out within 3 days.
> 
> I'm sure they'd be imaginative in their use of names too.

Yeah, this world would be so nice, if it weren't for all the *people*
in it.

We may have a loop: I didn't post that to NANOG, so far as I know; I
sent it to [EMAIL PROTECTED], and my copy back from taht list didn't
mention NANOG...

Cheers,
-- jra
-- 
Jay R. Ashworth   Baylink  [EMAIL PROTECTED]
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

 Those who cast the vote decide nothing.
 Those who count the vote decide everything.
   -- (Joseph Stalin)

Re: Spamhaus down?

[Marc Manthey]

hello gentleman

sorry for my offtopic response, but i got a lot of spam in the past  
days from a fake email at delphi.com
there is no email  at the delphi.com and the sender seems to be from  
an dynamic dsl account

it changes from different countrys .ar /co /pl
is there a way to get rid of it because this email exists since a few  
days and i never used it.


thanks for your time

Marc


Von: "Gämmerler" <[EMAIL PROTECTED]>
Datum: 12. Juni 2008 20:34:45 MESZ
An: <[EMAIL PROTECTED]>
Betreff: Das gibt es doch gar nicht - gibt es doch
Antwort an: "Gämmerler" <[EMAIL PROTECTED]>
Return-Path: <[EMAIL PROTECTED]>
Received: from mx1.mail.vrmd.de ([10.0.1.20]) by vm42.mail.vrmd.de  
(Cyrus v2.2.12-Invoca-RPM-2.2.12-8.1.RHEL4) with LMTPA; Thu, 12 Jun  
2008 19:58:39 +0200
Received: from vm47.bln1.vrmd.de ([81.28.224.157]  
helo=mx1.mail.vrmd.de) by mx1.mail.vrmd.de with esmtp (Exim 4.62)  
(envelope-from <[EMAIL PROTECTED]>) id 1K6r4J-0006eT-9P for [EMAIL PROTECTED] 
; Thu, 12 Jun 2008 19:58:39 +0200
Received: from 87.238.199.48/32:43217  
(from=<[EMAIL PROTECTED]>;helo=s9048.evanzo-server.de) by  
eXpurgate V2.1.1.1, id=150741::080612195838-6D82DAC0-E7D1EFAE with  
ESMTP for <[EMAIL PROTECTED]>; Thu, 12 Jun 2008 19:58:38 +0200

Received: (qmail 20858 invoked by uid 110); 12 Jun 2008 19:58:38 +0200
Received: (qmail 20846 invoked from network); 12 Jun 2008 19:58:37  
+0200
Received: from 201-212-173-150.net.prima.net.ar (HELO delphi.com)  
(201.212.173.150) by s9048.evanzo-server.de with SMTP; 12 Jun 2008  
19:58:31 +0200

X-Sieve: CMU Sieve 2.2
Envelope-To: [EMAIL PROTECTED]
Delivery-Date: Thu, 12 Jun 2008 19:58:39 +0200
Delivered-To: [EMAIL PROTECTED]
Message-Id: <[EMAIL PROTECTED]>
X-Accept-Language: en-us
Mime-Version: 1.0
Content-Type: multipart/related;  
boundary="023027716323052264238602"

X-Purgate: This mail is identified as Spam
X-Purgate: spam
X-Purgate-Type: spam
X-Purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net
X-Purgate-Id: 150741::080612195838-6D82DAC0-E7D1EFAE/ 
2337982772-2712154292/0-10

X-Purgate-Size: 26900/1513
X-Spam-Suspicion: Yes



--
"Imagination  is more important than  Knowledge".

Les enfants teribbles - research and deployment
Marc Manthey - head of research and innovation
Hildeboldplatz 1a D - 50672 Köln - Germany
Tel.:0049-221-3558032
Mobil:0049-1577-3329231
jabber :[EMAIL PROTECTED]
blog : http://www.let.de
ipv6 http://www.stattfernsehen.com
xing : https://www.xing.com/profile/Marc_Manthey

Best utilizing fat long pipes and large file transfer

[Sean Knox]

Hi,

I'm looking for input on the best practices for sending large files over 
a long fat pipe between facilities (gigabit private circuit, ~20ms RTT).
I'd like to avoid modifying TCP windows and options on end hosts where 
possible (I have a lot of them). I've seen products that work as 
"transfer stations" using "reliable UDP" to get around the windowing 
problem.


I'm thinking of setting up servers with optimized TCP settings to push 
big files around data centers but I'm curious to know how others deal 
with LFN+large transfers.


thanks,
Sean

Re: Best utilizing fat long pipes and large file transfer

[Kevin Oberman]

> Date: Thu, 12 Jun 2008 15:37:47 -0700
> From: Sean Knox <[EMAIL PROTECTED]>
> 
> Hi,
> 
> I'm looking for input on the best practices for sending large files over 
> a long fat pipe between facilities (gigabit private circuit, ~20ms RTT).
> I'd like to avoid modifying TCP windows and options on end hosts where 
> possible (I have a lot of them). I've seen products that work as 
> "transfer stations" using "reliable UDP" to get around the windowing 
> problem.
> 
> I'm thinking of setting up servers with optimized TCP settings to push 
> big files around data centers but I'm curious to know how others deal 
> with LFN+large transfers.

Not very fat or very long. I need to deal with 10GE over 200 ms (or more).

These should be pretty easy, but as you realize, you will need large
enough windows to keep the traffic in transit from filling the window
and stalling the flow. The laws of physics (speed of light) are not
forgiving.

There is a project from Martin Swaney at U-Delaware (with Guy Almes and
Aaron Brown) to do exactly what you are looking for.
http://portal.acm.org/citation.cfm?id=1188455.1188714&coll=GUIDE&dl=GUIDE
and
http://www.internet2.edu/pubs/phoebus.pdf
ESnet, Internet2 and Geant demonstrated it at last November's
SuperComputing Conference in Reno.

The idea is to use tuned proxies that are close to the source and
destination and are optimized for the delay. Local systems can move data
through them without dealing with the need to tune for the
delay-bandwidth product. Note that this "man in the middle" may not
play well with many security controls which deliberately try to prevent
it, so you still may need some adjustments.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751


pgpLXPMMiEqMd.pgp
Description: PGP signature

Re: Best utilizing fat long pipes and large file transfer

[Robert Boyle]

At 06:37 PM 6/12/2008, you wrote:
I'm looking for input on the best practices for sending large files 
over a long fat pipe between facilities (gigabit private circuit, ~20ms RTT).
I'd like to avoid modifying TCP windows and options on end hosts 
where possible (I have a lot of them). I've seen products that work 
as "transfer stations" using "reliable UDP" to get around the 
windowing problem.


I'm thinking of setting up servers with optimized TCP settings to 
push big files around data centers but I'm curious to know how 
others deal with LFN+large transfers.


In our experience, you can't get to line speed with over 20-30ms of 
latency using TCP regardless of how much you tweak it. We transfer 
files across the US with 60-70ms at line speeds with UDP based file 
transfer programs. There are a number of open source projects out 
there designed for this purpose.


-Robert



Tellurian Networks - Global Hosting Solutions Since 1995
http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
"Well done is better than well said." - Benjamin Franklin

Re: Best utilizing fat long pipes and large file transfer

[Randy Bush]

> The idea is to use tuned proxies that are close to the source and
> destination and are optimized for the delay. Local systems can move data
> through them without dealing with the need to tune for the
> delay-bandwidth product. Note that this "man in the middle" may not
> play well with many security controls which deliberately try to prevent
> it, so you still may need some adjustments.

and for those of us who are addicted to simple rsync, or whatever over
ssh, you should be aware of the really bad openssh windowing issue.

randy

Re: Best utilizing fat long pipes and large file transfer

[mdavis]

Take a look at some of the stuff from Aspera.

Mark


On Thu, Jun 12, 2008 at 03:37:47PM -0700, Sean Knox wrote:
> Hi,
> 
> I'm looking for input on the best practices for sending large files over 
> a long fat pipe between facilities (gigabit private circuit, ~20ms RTT).
> I'd like to avoid modifying TCP windows and options on end hosts where 
> possible (I have a lot of them). I've seen products that work as 
> "transfer stations" using "reliable UDP" to get around the windowing 
> problem.
> 
> I'm thinking of setting up servers with optimized TCP settings to push 
> big files around data centers but I'm curious to know how others deal 
> with LFN+large transfers.
> 
> thanks,
> Sean

Re: Best utilizing fat long pipes and large file transfer

[Randy Bush]

Karl Auerbach wrote:
> Randy Bush wrote:
>> and for those of us who are addicted to simple rsync, or whatever over
>> ssh, you should be aware of the really bad openssh windowing issue.
> I was not aware of this.  Do you have a pointer to a description?

see the work by rapier and stevens at psc



this is why rsync starts off at a blazing pace and then takes a serious
dive.

randuy

Re: Best utilizing fat long pipes and large file transfer

[Darren Bolding]

And while I certainly like open source solutions, there are plenty of
commercial products that do things to optimize this.  Depending on the type
of traffic the products do different things.  Many of the serial-byte
caching variety (e.g. Riverbed/F5) now also do connection/flow optimization
and proxying, while many of the network optimizers now are doing serial-byte
caching.

I also for a while was looking for multicast based file transfer tools, but
couldn't find any that were stable.  I'd be interested in seeing the names
of some of the projects Robert is talking about- perhaps I missed a few when
I looked.

One thing that is a simple solution?  Split the file and then send all the
parts at the same time.  This helps a fair bit, and is easy to implement.

Few things drive home the issues with TCP window scaling better than moving
a file via ftp and then via ttcp.  Sure, you don't always get all the file,
but it does get there fast!

--D

On Thu, Jun 12, 2008 at 5:02 PM, Randy Bush <[EMAIL PROTECTED]> wrote:

> > The idea is to use tuned proxies that are close to the source and
> > destination and are optimized for the delay. Local systems can move data
> > through them without dealing with the need to tune for the
> > delay-bandwidth product. Note that this "man in the middle" may not
> > play well with many security controls which deliberately try to prevent
> > it, so you still may need some adjustments.
>
> and for those of us who are addicted to simple rsync, or whatever over
> ssh, you should be aware of the really bad openssh windowing issue.
>
> randy
>
>


-- 
-- Darren Bolding --
-- [EMAIL PROTECTED] --

RE: Best utilizing fat long pipes and large file transfer

[Buhrmaster, Gary]

> Hi,
> 
> I'm looking for input on the best practices for sending large 
> files 

There are both commercial products (fastcopy)
and various "free"(*) products (bbcp, bbftp,
gridftp) that will send large files.  While
they can take advantage of larger windows
they also have the capability of using multiple
streams (dealing with the inability to tune the
tcp stack).  There are, of course, competitors
to these products which you should look into.
As always, YMWV.

Some references:
http://www.softlink.com/fastcopy_techie.html
  (Some parts of NASA seem to like fastcopy)
http://nccs.gov/user-support/general-support/data-transfer/bbcp/
  (Full disclosure, bbcp was written by someone who sits
  about 3 meters from where I am sitting, but I cannot find
  a nice web reference from him about the product, so I am
  showing a different sites documentation)
http://doc.in2p3.fr/bbftp/
  (One of the first to use multistream for BaBar)
http://www.globus.org/grid_software/data/gridftp.php
  (Part of the globus toolkit.  Somewhat heavier weight
  if all you want is file transfer.)
http://fasterdata.es.net/tools.html
  (A reference I am surprised Kevin did not point to :-)
http://www.slac.stanford.edu/grp/scs/net/talk/ggf5_jul2002/NMWG_GGF5.pdf
  (A few year old performance evaluation)
www.triumf.ca/canarie/amsterdam-test/References/010402-ftp.ppt 
  (Another older performance evaluation)


Gary


(*) Some are GPL, and some (modified) BSD licenses.
Which one is "free enough" depends on some strongly
held beliefs of the validator.

RE: Best utilizing fat long pipes and large file transfer

[Lincoln Dale]

> I'm looking for input on the best practices for sending large files over
> a long fat pipe between facilities (gigabit private circuit, ~20ms RTT).

providing you have RFC1323 type extensions enabled on a semi-decent OS, a 4MB
TCP window should be more than sufficient to fill a GbE pipe over 30msec.

with a modified TCP stack, that uses TCP window sizes up to 32MB, i've worked
with numerous customers to achieve wire-rate GbE async replication for
storage-arrays with FCIP.

the modifications to TCP were mostly to adjust how it reacts to packet loss,
e.g. don't "halve the window".
the intent of those modifications is that it doesn't use the "greater internet"
but is more suited for private connections within an enterprise customer
environment.

that is used in production today on many Cisco MDS 9xxx FC switch environments.


> I'd like to avoid modifying TCP windows and options on end hosts where
> possible (I have a lot of them). I've seen products that work as
> "transfer stations" using "reliable UDP" to get around the windowing
> problem.

given you don't want to modify all your hosts, you could 'proxy' said TCP
connections via 'socat' or 'netcat++'.


cheers,

lincoln.

comcast

[Thompson, Taeko]

 
Does anybody heard if comcast is having problems today?

Thank you,
Taeko

Re: comcast

[Matt Palmer]

On Thu, Jun 12, 2008 at 06:02:52PM -0700, Thompson, Taeko wrote:
> Does anybody heard if comcast is having problems today?

Since I got on shift two hours ago, I've done nothing but stare at
traceroutes into and out of Comcast space trying to reassure dozens of
customers that we're not down, Comcast is having problems.  Our upstream
claims they've been dealing with Comcast customers all (US) day.  I'm pretty
sure there's some serious weirdness going on in there.

(Oh, and don't reply to an existing message to start a new thread)

- Matt

Re: Best utilizing fat long pipes and large file transfer

[Robert E. Seastrom]

Randy Bush <[EMAIL PROTECTED]> writes:

> and for those of us who are addicted to simple rsync, or whatever over
> ssh, you should be aware of the really bad openssh windowing issue.

As a user of hpn-ssh for years, I have to wonder if there is any
reason (aside from the sheer cussedness for which Theo is infamous)
that the window improvements at least from hpn-ssh haven't been
backported into mainline openssh?  I suppose there might be
portability concerns with the multithreaded ciphers, and there's
certainly a good argument for not supporting NONE as a cipher type out
of the box without a recompile, but there's not much excuse for the
fixed size tiny buffers - I mean, it's 2008 already...

-r

Re: comcast

[Randy Bush]

> Does anybody heard if comcast is having problems today?

lucy was having problems in eugene orygun.  she diagnosed and then gave
up and went to dinner.

randy

Re: comcast

[Steve Pirk]

On Fri, 13 Jun 2008, Randy Bush wrote:


Does anybody heard if comcast is having problems today?


lucy was having problems in eugene orygun.  she diagnosed and then gave
up and went to dinner.

randy



I have a comcast business line in Western WA and have seen no hiccups
so far today. Main IP is 75.146.60.201.

If someone that is seeing issues can send me an IP, I can traceroute
to see if I can reach it from within Comcast.
--
Steve
Equal bytes for women.

Re: comcast

[Tom]

On Thu, 12 Jun 2008, Thompson, Taeko wrote:

Does anybody heard if comcast is having problems today?


I've got a customer in 73.72.92.0/24, and I don't see the prefix on the 
net.

RE: comcast

[Paul Stewart]

Just to confirm from here (Toronto):

core2-rtr-to#sh ip bgp 73.72.92.0
% Network not in table

Paul



-Original Message-
From: Tom [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 12, 2008 9:52 PM
To: [EMAIL PROTECTED]
Subject: Re: comcast

On Thu, 12 Jun 2008, Thompson, Taeko wrote:
> Does anybody heard if comcast is having problems today?

I've got a customer in 73.72.92.0/24, and I don't see the prefix on the
net.







"The information transmitted is intended only for the person or entity to which 
it is addressed and contains confidential and/or privileged material. If you 
received this in error, please contact the sender immediately and then destroy 
this transmission, including all attachments, without copying, distributing or 
disclosing same. Thank you."

RE: comcast

[ekagan]

> On Fri, 13 Jun 2008, Randy Bush wrote:
> 
> >> Does anybody heard if comcast is having problems today?
> >
> > lucy was having problems in eugene orygun.  she diagnosed 
> and then gave
> > up and went to dinner.
> >
> > randy
> >
> 
> I have a comcast business line in Western WA and have seen no hiccups
> so far today. Main IP is 75.146.60.201.
> 
> If someone that is seeing issues can send me an IP, I can traceroute
> to see if I can reach it from within Comcast.
> --
> Steve
> Equal bytes for women.
> 

I have Smokeping running from behind my Comcast (Eastern MA / New
England) and have alarms of latency from 6:28P-7:18pm EST.  Not sure if
attachments make it through - but doc of last 3 hr graph showing .13%
loss avg and 4.57% max loss.  Seems clean otherwise.  On Tuesday I had
alarms going all day long.I run monitors to my Corp Network and
Legacy Genuity DNS and the results are the same for both.

Eric
<>

Re: Best utilizing fat long pipes and large file transfer

[Kevin Oberman]

> Date: Fri, 13 Jun 2008 09:02:31 +0900
> From: Randy Bush <[EMAIL PROTECTED]>
> 
> > The idea is to use tuned proxies that are close to the source and
> > destination and are optimized for the delay. Local systems can move data
> > through them without dealing with the need to tune for the
> > delay-bandwidth product. Note that this "man in the middle" may not
> > play well with many security controls which deliberately try to prevent
> > it, so you still may need some adjustments.
> 
> and for those of us who are addicted to simple rsync, or whatever over
> ssh, you should be aware of the really bad openssh windowing issue.

Actually, OpenSSH has a number of issues that restrict performance. Read
about them at 

Pittsburgh Supercomputer Center fixed these problems and on FreeBSD, you
can get these by replacing the base OpenSSH with the openssh-portable
port and select the HPN (High Performance Networking) and OVERWRITE_BASE
options. I assume other OSes can deal with this or you can get the
patches directly from:


The port may also be built to support SmartCards which we require for
authentication. 
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751


pgpGIeZbnjikY.pgp
Description: PGP signature

RE: comcast

[David Prall]

Tom,
Where would that be located. From my house my UUNet/MCI/Verizon Business
Link doesn't have it. My speakeasy link doesn't have it either. All of
Comcast was out in my neighborhood (Alexandria, VA) yesterday at 7pm when I
got home, was still out at 11pm when I went to bed, up and running fine this
AM. 

David

--
http://dcp.dcptech.com
  

> -Original Message-
> From: Tom [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, June 12, 2008 9:52 PM
> To: [EMAIL PROTECTED]
> Subject: Re: comcast
> 
> On Thu, 12 Jun 2008, Thompson, Taeko wrote:
> > Does anybody heard if comcast is having problems today?
> 
> I've got a customer in 73.72.92.0/24, and I don't see the 
> prefix on the 
> net.

Re: comcast

[Christian]

when was the last time you saw this prefix reachable?

i dont see anything announced from comcasts 73.0.0.0/8 allocation within the
past 2 weeks...


On Thu, Jun 12, 2008 at 9:51 PM, Tom <[EMAIL PROTECTED]> wrote:

> On Thu, 12 Jun 2008, Thompson, Taeko wrote:
>
>> Does anybody heard if comcast is having problems today?
>>
>
> I've got a customer in 73.72.92.0/24, and I don't see the prefix on the
> net.
>
>

Re: Best utilizing fat long pipes and large file transfer

[Kevin Oberman]

> From: "Robert E. Seastrom" <[EMAIL PROTECTED]>
> Date: Thu, 12 Jun 2008 21:15:49 -0400
> 
> 
> Randy Bush <[EMAIL PROTECTED]> writes:
> 
> > and for those of us who are addicted to simple rsync, or whatever over
> > ssh, you should be aware of the really bad openssh windowing issue.
> 
> As a user of hpn-ssh for years, I have to wonder if there is any
> reason (aside from the sheer cussedness for which Theo is infamous)
> that the window improvements at least from hpn-ssh haven't been
> backported into mainline openssh?  I suppose there might be
> portability concerns with the multithreaded ciphers, and there's
> certainly a good argument for not supporting NONE as a cipher type out
> of the box without a recompile, but there's not much excuse for the
> fixed size tiny buffers - I mean, it's 2008 already...

Theo is known for his amazing stubbornness, but for area involving
security and cryptography, I find it hard to say that his conservatism
is excessive. Crypto is hard and often it is very non-intuitive. I
remember the long discussions on entropy harvesting and seeding in
FreeBSD which fortunately has cryptography professionals who could pick
every nit and make sure FreeBSD did not end up with Debian-type egg all
over its virtual face.

Than again, the tiny buffers are silly and I can't imagine any possible
security issue there. 
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751


pgpIfmjCKlkJK.pgp
Description: PGP signature

Re: comcast

[Jim Popovitch]

On Thu, Jun 12, 2008 at 10:24 PM, Christian <[EMAIL PROTECTED]> wrote:
> when was the last time you saw this prefix reachable?
>
> i dont see anything announced from comcasts 73.0.0.0/8 allocation within the
> past 2 weeks...

FYI: Internally within Comcast it does route:

$ mtr --report -c 1 73.0.0.1
HOST: blueLoss%   Snt   Last   Avg  Best  Wrst StDev
  1. linksys   0.0% 10.9   0.9   0.9   0.9   0.0
  2. c-24-98-192-1.hsd1.ga.comcas  0.0% 17.3   7.3   7.3   7.3   0.0
  3. ge-2-5-ur01.a2atlanta.ga.atl  0.0% 18.0   8.0   8.0   8.0   0.0
  4. te-9-1-ur02.a2atlanta.ga.atl  0.0% 16.0   6.0   6.0   6.0   0.0
  5. te-9-3-ur01.b0atlanta.ga.atl  0.0% 16.5   6.5   6.5   6.5   0.0
  6. 68.85.232.62  0.0% 16.4   6.4   6.4   6.4   0.0
  7. po-15-ar01.b0atlanta.ga.atla  0.0% 17.6   7.6   7.6   7.6   0.0
  8. te-4-1-cr01.atlanta.ga.cbone  0.0% 19.0   9.0   9.0   9.0   0.0
  9. te-1-1-cr01.charlotte.nc.cbo  0.0% 1   11.8  11.8  11.8  11.8   0.0
 10. te-1-1-cr01.richmond.va.cbon  0.0% 1   19.5  19.5  19.5  19.5   0.0
 11. te-1-1-cr01.mclean.va.cbone.  0.0% 1   24.0  24.0  24.0  24.0   0.0
 12. te-1-1-cr01.philadelphia.pa.  0.0% 1   25.6  25.6  25.6  25.6   0.0
 13. be-40-crs01.401nbroadst.pa.p  0.0% 1   26.5  26.5  26.5  26.5   0.0
 14. be-50-crs01.ivyland.pa.panjd  0.0% 1   28.8  28.8  28.8  28.8   0.0
 15. po-10-ar01.verona.nj.panjde.  0.0% 1   41.7  41.7  41.7  41.7   0.0
 16. po-10-ar01.eatontown.nj.panj  0.0% 1   33.5  33.5  33.5  33.5   0.0
 17. po-10-ur01.middletown.nj.pan  0.0% 1   34.4  34.4  34.4  34.4   0.0
 18. po-10-ur01.burlington.nj.pan  0.0% 1   48.0  48.0  48.0  48.0   0.0

-Jim P.

Re: comcast

[Christian]

interesting enough mine goes the other way

brokenrobot:~ christian$ traceroute 73.72.92.1
traceroute to 73.72.92.1 (73.72.92.1), 64 hops max, 40 byte packets
 1  192.168.2.1 (192.168.2.1)  12.130 ms  1.135 ms  1.262 ms
 2  * * *
 3  ge-2-3-ur01.jerseycity.nj.panjde.comcast.net (68.86.220.185)  10.710 ms
9.638 ms  12.299 ms
 4  po-10-ur02.jerseycity.nj.panjde.comcast.net (68.86.209.246)  15.747 ms
13.280 ms  10.082 ms
 5  po-10-ur01.narlington.nj.panjde.comcast.net (68.86.209.250)  11.373 ms
10.847 ms  11.873 ms
 6  po-10-ur02.narlington.nj.panjde.comcast.net (68.86.158.178)  36.034 ms
11.622 ms  16.032 ms
 7  po-70-ar01.verona.nj.panjde.comcast.net (68.86.209.254)  17.642 ms
16.334 ms  11.358 ms
 8  te-0-7-0-7-crs01.plainfield.nj.panjde.comcast.net (68.86.72.18)  25.986
ms  13.774 ms  12.524 ms
 9  te-4-1-cr01.newyork.ny.cbone.comcast.net (68.86.72.17)  22.172 ms
24.545 ms  17.774 ms
10  te-9-1-cr01.philadelphia.pa.cbone.comcast.net (68.86.68.5)  16.040 ms
14.670 ms  14.232 ms
11  te-9-1-cr01.mclean.va.cbone.comcast.net (68.86.68.1)  32.585 ms  20.303
ms  28.397 ms
12  te-9-1-cr02.pittsburgh.pa.cbone.comcast.net (68.86.68.125)  24.909 ms
24.261 ms  34.669 ms
13  te-8-1-cr01.cleveland.oh.cbone.comcast.net (68.86.68.117)  28.253 ms
26.949 ms  27.105 ms
14  te-9-1-cr01.chicago.il.cbone.comcast.net (68.86.68.22)  37.728 ms
59.564 ms  36.835 ms
15  te-9-1-cr01.omaha.ne.cbone.comcast.net (68.86.68.30)  53.805 ms  54.945
ms  53.015 ms
16  te-9-1-cr01.denver.co.cbone.comcast.net (68.86.68.42)  62.957 ms  74.028
ms  63.913 ms
17  te-9-1-cr01.denverqwest.co.cbone.comcast.net (68.86.68.146)  62.570 ms
68.635 ms  62.655 ms
18  te-2-1-cr01.santateresa.tx.cbone.comcast.net (68.86.68.150)  74.011 ms
74.431 ms  76.615 ms
19  te-8-1-cr01.losangeles.ca.cbone.comcast.net (68.86.68.81)  92.442 ms
93.805 ms  93.965 ms
20  te-9-1-cr01.sacramento.ca.cbone.comcast.net (68.86.68.69)  105.415 ms
102.575 ms  103.331 ms
21  te-0-2-0-1-ar01.oakland.ca.sfba.comcast.net (68.87.192.134)  111.564 ms
111.281 ms  106.768 ms
22  te-9-3-ur02.pittsburg.ca.sfba.comcast.net (68.87.192.133)  105.908 ms
105.997 ms  108.539 ms
23  GE-6-1-ur01.pittsburg.ca.sfba.comcast.net (68.87.199.173)  107.303 ms
108.250 ms  110.819 ms
24  ge-0-1-ubr02.pittsburg.ca.sfba.comcast.net (68.87.197.22)  119.945 ms *
107.782 ms


On Thu, Jun 12, 2008 at 10:35 PM, Jim Popovitch <[EMAIL PROTECTED]> wrote:

> On Thu, Jun 12, 2008 at 10:24 PM, Christian <[EMAIL PROTECTED]> wrote:
> > when was the last time you saw this prefix reachable?
> >
> > i dont see anything announced from comcasts 73.0.0.0/8 allocation within
> the
> > past 2 weeks...
>
> FYI: Internally within Comcast it does route:
>
> $ mtr --report -c 1 73.0.0.1
> HOST: blueLoss%   Snt   Last   Avg  Best  Wrst
> StDev
>  1. linksys   0.0% 10.9   0.9   0.9   0.9   0.0
>  2. c-24-98-192-1.hsd1.ga.comcas  0.0% 17.3   7.3   7.3   7.3   0.0
>  3. ge-2-5-ur01.a2atlanta.ga.atl  0.0% 18.0   8.0   8.0   8.0   0.0
>  4. te-9-1-ur02.a2atlanta.ga.atl  0.0% 16.0   6.0   6.0   6.0   0.0
>  5. te-9-3-ur01.b0atlanta.ga.atl  0.0% 16.5   6.5   6.5   6.5   0.0
>  6. 68.85.232.62  0.0% 16.4   6.4   6.4   6.4
> 0.0
>  7. po-15-ar01.b0atlanta.ga.atla  0.0% 17.6   7.6   7.6   7.6   0.0
>  8. te-4-1-cr01.atlanta.ga.cbone  0.0% 19.0   9.0   9.0   9.0   0.0
>  9. te-1-1-cr01.charlotte.nc.cbo  0.0% 1   11.8  11.8  11.8  11.8   0.0
>  10. te-1-1-cr01.richmond.va.cbon  0.0% 1   19.5  19.5  19.5  19.5
> 0.0
>  11. te-1-1-cr01.mclean.va.cbone.  0.0% 1   24.0  24.0  24.0  24.0
> 0.0
>  12. te-1-1-cr01.philadelphia.pa.  0.0% 1   25.6  25.6  25.6  25.6
> 0.0
>  13. be-40-crs01.401nbroadst.pa.p  0.0% 1   26.5  26.5  26.5  26.5
> 0.0
>  14. be-50-crs01.ivyland.pa.panjd  0.0% 1   28.8  28.8  28.8  28.8
> 0.0
>  15. po-10-ar01.verona.nj.panjde.  0.0% 1   41.7  41.7  41.7  41.7
> 0.0
>  16. po-10-ar01.eatontown.nj.panj  0.0% 1   33.5  33.5  33.5  33.5
> 0.0
>  17. po-10-ur01.middletown.nj.pan  0.0% 1   34.4  34.4  34.4  34.4
> 0.0
>  18. po-10-ur01.burlington.nj.pan  0.0% 1   48.0  48.0  48.0  48.0
> 0.0
>
> -Jim P.
>
>

Re: comcast

[Steven M. Bellovin]

On Thu, 12 Jun 2008 22:01:03 -0400
<[EMAIL PROTECTED]> wrote:

> > On Fri, 13 Jun 2008, Randy Bush wrote:
> > 
> > >> Does anybody heard if comcast is having problems today?
> > >
> > > lucy was having problems in eugene orygun.  she diagnosed 
> > and then gave
> > > up and went to dinner.
> > >
> > > randy
> > >
> > 
> > I have a comcast business line in Western WA and have seen no
> > hiccups so far today. Main IP is 75.146.60.201.
> > 
> > If someone that is seeing issues can send me an IP, I can traceroute
> > to see if I can reach it from within Comcast.
> > --
> > Steve
> > Equal bytes for women.
> > 
> 
> I have Smokeping running from behind my Comcast (Eastern MA / New
> England) and have alarms of latency from 6:28P-7:18pm EST.  Not sure
> if attachments make it through - but doc of last 3 hr graph
> showing .13% loss avg and 4.57% max loss.  Seems clean otherwise.  On
> Tuesday I had alarms going all day long.I run monitors to my Corp
> Network and Legacy Genuity DNS and the results are the same for both.
> 
I didn't get online tonight till ~8pm, but I haven't noticed any
problems at all.  (I'm on 74/8.)


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: comcast

[Forsaken]

On Thu, 12 Jun 2008 18:02:52 -0700
"Thompson, Taeko" <[EMAIL PROTECTED]> wrote:

They've been fine in my area (atlanta), though there was a fair bit of
downtime last week. I did, however, notice today that my port 25 blocks
are gone... which wasn't the case last week.

>  
> Does anybody heard if comcast is having problems today?
> 
> Thank you,
> Taeko
> 

Re: comcast

[Martin Hannigan]

On Thu, Jun 12, 2008 at 10:35 PM, Jim Popovitch <[EMAIL PROTECTED]> wrote:

>  18. po-10-ur01.burlington.nj.pan  0.0% 1   48.0  48.0  48.0  48.0   0.0

 23   114 ms   122 ms   113 ms  ge-0-1-ubr02.pittsburg.ca.sfba.comcast.net [68.8
7.197.22]

Für eine Weile hatten wir Zugang durch eine Hong Kong basiert Piraten-Netzwerk

-M<

Re: comcast

[Jim Popovitch]

On Thu, Jun 12, 2008 at 11:34 PM, Martin Hannigan <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 10:35 PM, Jim Popovitch <[EMAIL PROTECTED]> wrote:
>
>>  18. po-10-ur01.burlington.nj.pan  0.0% 1   48.0  48.0  48.0  48.0   0.0
>
>  23   114 ms   122 ms   113 ms  ge-0-1-ubr02.pittsburg.ca.sfba.comcast.net 
> [68.8
> 7.197.22]
>
> Für eine Weile hatten wir Zugang durch eine Hong Kong basiert Piraten-Netzwerk

Yeah, I've saw similar in traces a few days back, I wondered wtf.

-Jim P.

Re: Best utilizing fat long pipes and large file transfer

[Michal Krsek]

Hi Sean,
from thursday, we have copied some ~300 GB packages from Prague to San 
Diego (~200 ms delay, 10 GE flat ethernet end machines connected via 
1GE) files using RBUDP which worked great.


Each scenario needs some planning. You have to answer several questions:
1) What is the performance of storage subsystem (sometimes you need to 
connect external harddrives or tape robot)

2) How many files you need to transfer?
3) How big are these files?
4) What is the consistency scenarion (it is file consistency or package 
consistency)?


In example, I've sent some film data. Lot (~30.000) of 10 MB DPXes. 
Consistency was package based. Harddrives have been at the beggining 
connected via iLink (arrived on this media), then moved to eSATA (went 
to shop, bought another drive and connected it into export machine). 
Main tuning for RBUDP has been to buy another harddrive and tar these files.


  Regards
 Michal


Hi,

I'm looking for input on the best practices for sending large files 
over a long fat pipe between facilities (gigabit private circuit, 
~20ms RTT).
I'd like to avoid modifying TCP windows and options on end hosts where 
possible (I have a lot of them). I've seen products that work as 
"transfer stations" using "reliable UDP" to get around the windowing 
problem.


I'm thinking of setting up servers with optimized TCP settings to push 
big files around data centers but I'm curious to know how others deal 
with LFN+large transfers.


thanks,
Sean