- Test - lists.nanog.org

Hello, @Home?
by Adam Rothschild 09 Feb '98

09 Feb '98

Uh... Could someone from @H please contact me privately, ASAP?!? Put simply, your connectivity at SprintNAP and [the Parking Garage Commonly Referred to as] MAE-East sucks at the moment. Your phone support leaves much to be desired in terms of competency and responsiveness. BTW, thanks to everyone who contacting me re: cross-country connectivity. I have a gazillion FR price quotes headed my way... :) Thanks, Adam -- ---------------------------------------------------------- Adam Rothschild <asr(a)millburn.net> CTO / Senior Systems Engineer http://www.millburn.net millburnNET inter@ctive

2 3

Re: nanog discussion of HTTP 1.1
by Henrik Frystyk Nielsen 09 Feb '98

09 Feb '98

Hi Marc, I have not been on this list for long but please allow me to elaborate on some of the points in this mail. >> Phil Howard writes: >> > By loading the images in parallel, with the initial part of the image files >> > being a fuzzy approximation, you get to see about where every button is >> > located, and in many cases you know exactly what it is, and you can click >> > on them as soon as you know where to go. >> >> By loading the images in parallel over multiple TCP connections, you >> also totally screw the TCP congestion avoidance mechanisms, and hurt >> the net as a whole, especially given how prevalent HTTP is these days. >> Unfortunately, as has been seen here, very few people working with the >> net these days actually understand the details of things the net >> depends on, and TCP congestion avoidance is one of them. >> >> HTTP 1.1 allows multiplexing in a single stream, and even (amazingly > >Once again, HTTP/1.1 does _not_ allow multiplexing multiple transfers >simlultaneously in a single TCP connection. Multiple responses are >serialized. To be precise, an HTTP/1.1 client can issue multiple requests on the same TCP connection without waiting for the responses to previous requests. The requests as well as the responses do not change order while transferred and are not interleaved - it is strictly a question of timing. You can find a more detailed in our paper http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html which you refer to as well as out HTTP performance overview at http://www.w3.org/Protocols/HTTP/Performance/ >> enough) ends up working faster in practice than multiple TCP >> connections. > >I have seen nothing supporting that assertion for high latency, medium >(aka. the Internet on a good day) packet loss connections. The discussion >at: > > http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html > >shows some interesting information about the wins of persistent >connections and piplining, however their tests only went as far as >including a 28.8k local dialup, which does not simulate the "average user" >going to the "average web site". This is not entirely correct - the paper discusses the effect of HTTP/1.1 buffering and pipelining in three network environments: WAN between LBL and MIT LAN (10 Mbit) PPP over 28.8 modem Our tests show that in all three environments, HTTP/1.1 using a single TCP connection outperforms HTTP/1.0 using 6 simultaneous connections. In both the LAN and the WAN case the number of TCP packets used by HTTP/1.1 dropped to about 1/3 and time spent to about 1/2 in direct comparison between HTTP/1.1 and HTTP/1.0. The savings in the PPP case are more modest due to the low bandwidth. I should say that we used the W3C libwww as the client side HTTP/1.0 and HTTP/1.1 implementations and Apache and Jigsaw as HTTP/1.1 servers. The client side pipelining code is available from http://www.w3.org/Library/ > If you are dropping packets and >congestion contol is coming into play, you may see more impact when using >one connection that is temporarily stalled than multiple connections, with >the hope that at least one will be sending at any time. I am not aware of >any research to support (or deny, for that matter) this view, however >AFAIK there is a general lack of published research on the interaction >between HTTP w/pipelined and persistent connections and the Internet. While the absolute time spent in our WAN experiments varied greatly over the cause of the day (low in the morning, high in the afternoon, ET) the relative difference between HTTP/1.0 and HTTP/1.1 was fairly constant even when we experienced high packet loss (some links litterely went down while we ran the tests). >As I have already pointed out to Paul, but think it deserves to be >emphasized because it is not apparent to many, they do _not_ do pipelined >connections but only persistent connections. You can not do reliable >pipelined connections with HTTP/1.0. The difference between pipelined >persistent and non-pipelined persistent connections (in the case where >there are multiple requests to the same server in a row) is one RTT per >request plus a possible little bit from merging the tail of one response >with the head of another into one packet. You can easily fit 4-5 HTTP requests into the same TCP packet and similarly, HTTP servers can send responses back to back without starting a new packet. For example, in the case of cache validation responses it is possible to fit 4-5 responses into the same TCP packet. Together with a lot less context swaps, the overall result is that servers cool down quite a bit, see http://www.w3.org/Protocols/HTTP/Performance/System/SysCalls.html I should point out that existing Web applications actually have a reason for using HTTP/1.0 the way they do - it allows them to get the metadata for the inlined objects faster and hence they can lay out the page much sooner - a crucial factor in the browser battle. Pipelining doesn't fully solve this problem. >Also worthy of note is that the only widespread client that implements >HTTP/1.1 is MSIE4, and even it is botched badly, although not as badly as >4.0b2 was. (eg. it sometimes sent 1.1 requests but would only accept 1.0 >responses) Scott Lawrence maintains a HTTP/1.1 implementor's forum where implementors can get together and test their HTTP/1.1 implementations on a regular basis: http://www.w3.org/Protocols/HTTP/Forum/ If you find bugs or problems in any of the implementations that participate in the test (listed on the page above) then you should send a mail to the list <w3c-http(a)w3.org>, which is described in http://www.w3.org/Protocols/#Lists Thanks, Henrik -- Henrik Frystyk Nielsen, <frystyk(a)w3.org> World Wide Web Consortium http://www.w3.org/People/Frystyk

1 0

Re: smurf... still?
by Tatsuya Kawasaki 08 Feb '98

08 Feb '98

Dear Daniel, Sorry that I have mislead you to the Hookup. As you might know already, Hookup went backrupt a few months ago. And all what they had is NOW break into a few company's. I believe this might give you "real" start. According to nslookup, "hookup.net" is currently upated by hookup.net nameserver = ns1.nbc.netcom.ca hookup.net nameserver = ns2.nbc.netcom.ca So, I lookup whois data base for netcom.ca. I got [No name] (NS18559-HST) Hostname: NS1.NBC.NETCOM.CA Address: 207.181.89.2 System: ? running ? Coordinator: Bignell, Graham (BG54-ORG) netcom(a)THE.ENTIRE.NET 416 341 5776 Fax- - - 416 341 5725 Record last updated on 21-Jan-97. Database last updated on 8-Feb-98 04:14:24 EDT. So, I think this might be a good start. I should have looked further before informed you. regards, tatsuya ------------------------------------------------ = = = = = = 電話 03-3239-0607 fax 03-3239-2609 business network telecom http://www.giganet.net On Sun, 8 Feb 1998, Daniel Reed wrote: > On Thu, 5 Feb 1998, Tatsuya Kawasaki wrote: > ) On Tue, 3 Feb 1998, Craig A. Huegen wrote: > ) > On Wed, 4 Feb 1998, Tatsuya Kawasaki wrote: > ) > mskucher is no longer with hookup; and, in fact, hookup has filed for > ) > bankruptcy, last I heard. > ) Daniel, > ) if you need information about upper provider or the letter > ) mskucher sent, please let me know. I think he also CC to nanog, too. > Welp, I've waited until now, and just tried again: > > root@narnia:~# ping -c2 165.154.1.255 > PING 165.154.1.255 (165.154.1.255): 56 data bytes > 64 bytes from 165.154.125.53: icmp_seq=0 ttl=243 time=365.8 ms > 64 bytes from 165.154.1.1: icmp_seq=0 ttl=242 time=459.9 ms (DUP!) > 64 bytes from 165.154.1.7: icmp_seq=0 ttl=242 time=462.0 ms (DUP!) > 64 bytes from 127.0.0.2: icmp_seq=0 ttl=242 time=463.8 ms (DUP!) > 64 bytes from 165.154.1.66: icmp_seq=0 ttl=242 time=466.9 ms (DUP!) > 64 bytes from 165.154.1.57: icmp_seq=0 ttl=242 time=496.9 ms (DUP!) > 64 bytes from 165.154.1.4: icmp_seq=0 ttl=242 time=506.9 ms (DUP!) > 64 bytes from 165.154.1.8: icmp_seq=0 ttl=242 time=537.0 ms (DUP!) > 64 bytes from 165.154.1.26: icmp_seq=0 ttl=242 time=556.9 ms (DUP!) > 64 bytes from 165.154.1.21: icmp_seq=0 ttl=242 time=576.7 ms (DUP!) > 64 bytes from 165.154.1.26: icmp_seq=1 ttl=242 time=288.5 ms > > --- 165.154.1.255 ping statistics --- > 2 packets transmitted, 2 packets received, +10 duplicates, 0% packet loss > round-trip min/avg/max = 288.5/477.3/576.7 ms > root@narnia:~# > > I originally contacted registry(a)hookup.net (as per the output from whois > 165.154), but it appears they haven't fixed the problem. I'm unsure where > to go from here (should I contact Netcom, do you think?), but there was > only two networks listed in that smurf.c derivative that were susceptable > to being used in a smurf attack anyway, so I'm not really sure it's > entirely worthwhile persuing those two contacts. > > -- > Daniel Reed <n(a)narnia.n.ml.org> (3CE060DD) > System administrator of narnia.n.ml.org (narnia.mhv.net [199.0.0.118]) > recursive (adj.) - See recursive. > >

1 0

Re: FDDI or 100Mb Ethernet
by Sean M. Doran 08 Feb '98

08 Feb '98

| > SM FDDI -> SM POS. Problem solved. Reuse your fibre, even. | | *cough* Um, hate to have to raise an ugly bugaboo, but reusing | the fibre isn't the problem; it's redesigning the whole network | architecture from multidrop, ring based FDDI, to point-to-point | POS connections. Multipoint? Ha! Your architecture should be around an FDDI switch anyway, then all you do is unplug all the SM (or MM if that suits you) from the switch(es) and plug them into your wonderful Cisco 12012 populated with OC3 cards. If you really want it to look like LANnish still, run MPLS. | Or are you going to point out a cheap (~$100,000) SONET switch | that will work as a relatively "drop-in" replacement for already | installed DEC Gigaswitches? If you know of one 120xx. You really don't want to put too many 155-size interfaces into a 75xx router anyway thanks to the fun backplane (so you are limited in potential choices anyway), but you probably want two POS cards, one to 12012 "A" and one to 12012 "B". Traffic managment will be fun, but hey, you are wizardly at multihoming and stuff already, right? So that should be easy-peasy by comparison. | I'll order a half dozen. Otherwise, there really isn't any | multi-drop replacement for FDDI at this point. Hm, go back and look at the POP design I postulated the other day. Note that MPLS can run over many media, if you really want things to look like a single level two fabric... Sean. ("It's kinda like ATM done mostly right")

1 0

Re: FDDI or 100Mb Ethernet
by Sean M. Doran 08 Feb '98

08 Feb '98

Paul Ferguson <ferguson(a)cisco.com> writes: > Okay. Playing my usual devil's advocate role, please tell me what > migration path lies beyond FDDI for faster connectivity? SM FDDI -> SM POS. Problem solved. Reuse your fibre, even. Your inventive marketing friend, Sean.

2 1

Re: MTU of the Internet?
by Sean M. Doran 08 Feb '98

08 Feb '98

Paul A Vixie <paul(a)vix.com> writes: > desktop tcp stack fixes to remember end-to-end bandwidth*delay between > connections, and to treat end-to-end bandwidth*delay as an aggregate to be > shared between simultaneous connections from/to the same > place By "desktop tcp stack fixes" you mean at the server side in the case of HTTP transfers, I guess. Ow, no. Well, maybe you can share a congestion window across multiple TCP streams such that you only occupy the number of buffers a single uninterfered-with TCP stream would. The idea is that there is space for N packets between the source and the destination, and what they are occupied by is immaterial. Provided that dupack/ecn/timeout all affect the total congestion window to a particular destination, preserving additive increase/multiplicative back-off, this might work. However you would have to think very hard about it (I'd suggest involving the usual e2e researcher types before you do a real deployment) and it's not clear it would really buy you anything over a single TCP flow anyway. Anything that introduces more traffic than would be discovered by a single uninterfered-with TCP flow is bad news. In particular, ramping up suddenly based on historical conditions is unsafe. I hate to say it but an obvious push-back mechanism is per-packet charging (people are already charging by the byte for web hosting), and it is in the interests of self defence for web hosts to maximise their efficiency in the face of this. Another obvious push-back is work along the lines that VJ has been campaining for in his "penalize things that are not in profile (with a normal TCP impl.)" talks. > (or to just stop doing that stupid parallelism in favour > of one http/1.1 persistent connection) would also help. This is the appropriate solution. Sean.

1 0

Re: MTU of the Internet?
by Sean M. Doran 08 Feb '98

08 Feb '98

Paul A Vixie <paul(a)vix.com> writes: > yes. this is why we have a window scale tcp option now. and this buffer > requirement is per end-host, whether there are multiple tcp sessions or > just one. You need to support approximately a window worth of buffering in each device along the path where there is the possibility of transient congestion; this turns out to mean you need approximately the line bandwidth * ca. 400ms per link (or at least space for a decent delay * bandwidth product on very very fast links). See the work by Guy Almes et al. on the T3 NSFNET link to Hawaii, and endless rants by me, Peter and Curtis. So, big amounts of unacknowledged data == big amounts of buffer. Big amounts of buffer not being used == big amounts of space for TCP to fill probe into and fill up. Bad news for a number of reasons. Meet RED, which keeps buffer occupation small, leaving it available for dealing with transient congestion so already-transmitted unacknowledged data from far away don't get lost when someone clicks on a web page or starts an FTP or something. > at least one satellite ip provider is evaluating transparent caching as a > way to obviate these effects by aggregating dumb-client connections into > something smarter for the sky link. At least six such companies have wandered into the offices of either me or my managing director in the past three months. At least four other companies have telephoned. Just FYI. --:) > > So, if you have a system with per-connection bufffering, and > > that hits a "speed limit" of 512 kbits/sec over your satellite T1, > > you can raise the speed up to the full T1 by opening 3 streams. Thus > > more connections == faster downloads. > > it's still the same amount of buffering per end host though. The amount of per-interface buffering on routers is a function of the propagation delay and bandwidth of the network, optimally, whether there is one flow or ten flows or ten thousand flows passing through. This buffering is more of a "speed limit" based on limited experiments done with various satellites used for real circuit transatlantic circuit restoration than host buffering is. The problem is that a short transient spike comes along and eats a couple of segments in a very wide window, causing slow-start. This often happens well away from the pair of routers on either end of the satellite connection, from anecdotal evidence. > > ... The same group ... did some satellite testing, trying > > a parallel FTP client they had. They benchmarked 1, 2, 4, 8, and 16 > > streams between two SunOS 4 boxes over a T1 satellite (500ms RTT). > > Maximum performance (shortest transfer time) was achieved with 4 > > TCP streams. > > that's got more to say about the sunos tcp implementation than about tcp > as a protocol. No, it has more to say about the test methodology. It is difficult to interfere with your own packets, if you have only one interface to transmit on... A better small-scale test would involve several sinks and sources clustered around a router that does not impose a round-robin or similar serialization scheme on inbound packets, combined with a "burst generator" which sends traffic across that single router, interfering with stuff coming down from the satellite. Cisco to their credit has in the past spent lots of time studying this based on some studies led by Curtis and others of the performance of the Bellcore ATM NAPs, and some other experience garnered here and there. Other vendors are probably not ignorant of these testing methodoligies... Anyone at ANS who wants to talk about the IBM traffic recorder is welcome to do so. :) Sean.

1 0

HEllo to any on NM
by Alex Rubenstein 08 Feb '98

08 Feb '98

This is absolutely, no way in any way, shape, or form, and operational issue. Anything going on this afternoon in Albequerque?

1 0

Re: MTU of the Internet?
by Paul A Vixie 08 Feb '98

08 Feb '98

this was sent to me personally but seems generally relevant. > There is at least one case where multiple connections will > be faster, and I suspect there are actually several. tcp without congestion avoidance is always faster than tcp with congestion avoidance. whether you take away congestion avoidance by running lots of short lived connections in parallel, or whether you actually dyke out the code that avoids congestion, the result is the same: other tcp's will back off and give you more of the channel. this is another example of a cooperative protocol suite trying to survive in a competitive world. that tcp only behaves well if all other tcp's behave well, where "behaves well" means "shares paths fairly" creates an automatic incentive on the part of some designers to not "behave well" so they can get more than their fair share. this feeds directly into arguments about flat rate, peering, open smtp relays, checking of source addresses on egress gateways, and the rest of the usual nanog chatter. > [there is a] paper on TCP performance over satellite links > (really any long-fat-pipe), and [there is] a lot about TCP performace > I would have never expected. One of the simpler ideas is the > "TCP speed limit". You must have buffer space that is greater than the > bandwidth * delay product to keep the pipe full. yes. this is why we have a window scale tcp option now. and this buffer requirement is per end-host, whether there are multiple tcp sessions or just one. > On very high delay > links (satellite) or very high bandwidth (OC-3/OC-12 to the desktop) > current workstations don't allocate enough buffers, either system > wide or per-connection. at least one satellite ip provider is evaluating transparent caching as a way to obviate these effects by aggregating dumb-client connections into something smarter for the sky link. > So, if you have a system with per-connection bufffering, and > that hits a "speed limit" of 512 kbits/sec over your satellite T1, > you can raise the speed up to the full T1 by opening 3 streams. Thus > more connections == faster downloads. it's still the same amount of buffering per end host though. > ... The same group ... did some satellite testing, trying > a parallel FTP client they had. They benchmarked 1, 2, 4, 8, and 16 > streams between two SunOS 4 boxes over a T1 satellite (500ms RTT). > Maximum performance (shortest transfer time) was achieved with 4 > TCP streams. that's got more to say about the sunos tcp implementation than about tcp as a protocol. > I'll throw in one more subjective measure. When Netscape > first came out some of the CS people at Virginia Tech wondered about > the perception, and did some tests with willing college student > subjects using Mosaic (which at the time supported HTTP keepalives, > and used them to connect to the server once for all transfers) > and Netscape (multiple connections, no keepalives). > ... > On the more complex pages Mosaic downloaded and displayed the > page faster, in wall clock time, but the users always preferred > Netscape. The observation is that many people don't wait for > a full download, they click on picture links, for instance, > when they are half down....so having them all half down allows someone > to proceed with browsing, rather than having half fully there, and > half not visable. which means the server gets a lot of RSTs and a lot of data which is committed into the path ends up being thrown away. seems like if we wanted things to go faster, we would waste less bandwidth by sending only data which was useful and not creating a huge number of retrans- missions by effectively turning off tcp congestion avoidance. > ... - I would suspect that two connections > with keepalives would be optimum....you get multiple stream advantages, > minimize load on the server, and can drive those two connections > fast (past slow-start) as they are long lived. i agree. too bad the browser manufacturers are driven by competition rather than cooperation. of course, human nature has in this case created a product opportunity in transparent caching.

2 1

real video xmission of NANOG
by Sean M. Doran 08 Feb '98

08 Feb '98

Hi Bill et al - Have I missed the promised details of the Real Video transmission of the NANOG conference? Also, is there any chance you could also provide a recorded copy for download for those people who are time-zone or work-load impaired? Sean.

1 0