x
<<   <   Page 2 / 4   >   >>
gbennett 12/4/2012 | 11:41:55 PM
re: And Furthermore, Bill... Hi ironccie,

Thanks for those kind words. It's true that the anonymity provided by the message boards does sometimes make people say things in a way they probably wouldn't if they were speaking face to face, or even over a phone. In fact, one of our posters even apologised for doing so...

http://www.lightreading.com/bo...

...which I think was damn decent of him/her.

In terms of on/off topic, the Linux users have a point. But I'll get to that in another post :-)

On your second issue. I agree, fragmentation has been with us forever, and I think everyone can agree that it's bad for the hosts and the network.

What amazed me was the proportion of fragments generated by Media Player. Now the good news is that we've had a comment back from Microsoft on this, and as you'd expect the situation isn't as clear cut as the CAIDA report makes out. We're currently hoping to get Microsoft to comment on the record, and I've also dropped a mail to the report authors.

Stay tuned!

Cheers,
Geoff
wannaw 12/4/2012 | 11:41:49 PM
re: And Furthermore, Bill... FYI..

Exchange server will do other protocols beside Microsoft's proprietary IMAP4..including POP3/SMTP.

However, if you want all the extras in Outlook, like your contacts folder staying on the server, you have to use IMAP4.

If you're just looking to get your email, POP3 is the way to go.

Now, you just need to convince your MIS team to turn them on. Good luck with that.
mr zippy 12/4/2012 | 11:41:47 PM
re: And Furthermore, Bill...
"I ran a Red Hat system on a 200MHz Pentium Pro for several years, but for real work I always went back to Windows. For me the killer app was Powerpoint, closely followed by Word."

Things have changed a bit since then ... as I mentioned before, Open Office is a creditable replacement for MS Office, Magicpoint (http://www.magicpoint.org) also seems to be a capable replacement for Powerpoint.

"I haven't used the latest Linux office equivalents you mention, but IMHO if Linux really wants to be a Windows replacement, the developers should forget about O/S features for a few months and get working on the Office suite."

That wouldn't be fun for the kernel developers at all !

Since the growing "corporatisation" of Linux, people think the Linux developers' goal is to come up with a replacement for Windows.

It isn't.

They do it just for fun.

If, as a side effect, it can replace Windows, that might also be good, as Billy G doesn't really need any more money. It is not even worth his time to pick up $500 if it falls out of his pocket, onto the ground.

busted 12/4/2012 | 11:41:46 PM
re: And Furthermore, Bill... I have an old beast of a machine that I want to run Linux on. No OS and I can't boot off the CD. Any recomendations on how to install from floppy.
doco 12/4/2012 | 11:41:36 PM
re: And Furthermore, Bill... Get a boxed copy of Mandrake. You can download and burn the ISOs to a CD-R, but you still need the patience to download 3x650 MB of stuff.

You can make a boot floppy from a Windows machine that will load the CD-ROM driver and then proceed to install everything else from the CD. There is a ReadME file on the first CD that gives instructions - or go to the Mandrake.org website.

I did a floppy only install about 8 years ago and it was about 50 floppys at that time. Not something to do today - it's cheaper to buy a CDROM drive than to buy all those floppys. Not to mention quicker and less frustrating.
lcw 12/4/2012 | 11:41:34 PM
re: And Furthermore, Bill... I'm pretty sure Windows does implement RFC 1191. Perhaps it's broken for UDP? Perhaps the referenced paper was mislabeling the traffic?

My beef with PMTU Discovery is that it relies on ICMP messages getting back to the source, which is hardly a sure thing. Firewalls and edge routers are routinely configured to block all ICMP. And, the "PMTU Black Hole discovery" algorithm that supposedly addresses identifies this is sluggish beyond any normal user's patience.

PMTU Discovery would be much less troublesome if it worked similar to ICMP redirects. I.e., if it fragmented and forwarded the packet AND generated a packet-too-big message.

Best advice -- any public web site ought to set a maximum MTU of 1400 or less.

(Note that on IOS routers you can use 'ip tcp adjust-mss xxx' now to enforce a lower MSS when you know tunneling will occur)
skeptic 12/4/2012 | 11:41:32 PM
re: And Furthermore, Bill... PMTU Discovery would be much less troublesome if it worked similar to ICMP redirects. I.e., if it fragmented and forwarded the packet AND generated a packet-too-big message.
-------------------
PMTU worked because it used the existing
dont-fragment bit in the IP header. The difficult
aspect of what your suggesting is that it would
either eliminate the expected dont-fragment
behavior (which would be bad) or we would have
to come up with another bit in the IP header
(which isn't likely).

As far as windows goes, its been the case that
often even if they implement an RFC, they get
it wrong. It seemed like it took them years
to even get the basic TCP functionality
operating normally.

I know why it ends up happening, but blocking
all ICMP at firewalls is a bad idea. It should
be a selective filter.

dcaulton 12/4/2012 | 11:41:31 PM
re: And Furthermore, Bill... Thanks to Lightreading for their attention to this topic! I'm the Group Product Manager for the Windows Digital Media Division at Microsoft, and I have a few thoughts.

First, if you dig into the journal article, they identify applications with simple mapping to ports, and in cases where multiple apps use a port, the majority user gets the category. Thus, (If IGÇÖm interpreting this correctly), all GÇ£streamingGÇ¥ is being mapped to GÇ£MicrosoftGÇÖs RealMedia PlayerGÇ¥ (sic). Note that in their tables, the Media player accounts for 100% of the streaming categoryGÇÖs packets. In any case, I think that the large packet sizes typically associated with all streaming media encoding (not just Windows Media Player), combined with the large file sizes, leads to their result. Thus the real observation here is that streaming in general uses a lot of packets and large packet sizes.

Actually, itGÇÖs imprecise to use port assignments to identify GÇ£streamingGÇ¥. Streaming from Windows Server 2003 can happen over rtsp, http, mms, or multicast (I suspect in this case most of the fragmentation is on the mms protocol). In addition, the player often accesses content via http download from web servers. Thus, many different ports can be doing streaming, and much of this traffic is probably getting misallocated as being other applications.

In any case, I'm happy to report that we have already fulfilled your request. ItGÇÖs actually the encoder that sets packet size, and the server that sends the packets - so that's where enhancement is needed. In Windows Server 2003, weGÇÖve added full support for ipv6, which reduces fragmentation as you note. We also allow the encoder to select smaller packet sizes, and the Server now streams in RTSP, and can repacketize encoded media to reduce packet size dynamically. WeGÇÖre the only streaming platform to do these things, by the way GÇô neither QuickTime and Real support both of these features. It would be interesting to rerun the fragmentation measurements with Windows Media Player 9 Series and Windows Server 2003; I suspect fragmentation would be dramatically reduced.
mr zippy 12/4/2012 | 11:41:25 PM
re: And Furthermore, Bill... "My beef with PMTU Discovery is that it relies on ICMP messages getting back to the source, which is hardly a sure thing. Firewalls and edge routers are routinely configured to block all ICMP. And, the "PMTU Black Hole discovery" algorithm that supposedly addresses identifies this is sluggish beyond any normal user's patience."

The problem you are describing (ICMP being blocked), is nothing to do with PMTUD being mis-designed.

It is firewall admins who don't known enough to be firewall admins ("who are these people!").

Checkbox number 2 when configuring a firewall is to make sure you "ICMP Destination Unreachable, Packet Too Big" messages can make it from the outside to the inside (via appropriate firewall methods eg. stateful inspection etc.,)

"Best advice -- any public web site ought to set a maximum MTU of 1400 or less. "

The only problem with this advice is it works around the mis-configuration, rather than forcing the root cause to be fixed, namely firewall mis-configuration.

Longer term, we would end up with an Internet with an Internet with a less efficient MTU.

pdt 12/4/2012 | 11:41:17 PM
re: And Furthermore, Bill... Hi wannaw,

Yes. problem is to make MIS make these features available. They want the smallest number of features enabled to make their job easier. This I can understand.

The other problem is when you use all the extra exchange features in outlook it looks very good and functional. but is only ever shown on the LAN! First time to make synchronisation on the dial up you see the real problem.

I am not an expert but somebody has told me that to delete a file you need to download it first, and if it has big file attachments this is why it can take a long time! Once I was in hotel, and started synchronising and went to dinner, then to bar afterwards and when I get back it was STILL synchronising. This is crazy.

Solution is to make exchange and outlook programmers work with phone line for one month and see how they like it.
<<   <   Page 2 / 4   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE