Re: Rf Id tag protocol
% Anyone is interested to help me to write a protocol for the Rf ID? % Thanks in advance % % giuseppe canale what kind of protocol did you have in mind? you might want to review the EPC or auto-id center web pages to see what has already been done in this area. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise).
Re: i18n name badges
I think having the punycode form have no "value" on a name badge. Punycode, as it is designed, is meant for machine-to-machine communication. But I like the idea of allowing participation to put their own native names together with their ASCII version on the name badge especially for the next IETF. But... 1. What if the person don't have ASCII only name? (e.g. Patrik Fältström) 2. What if the person have a name which the computer cant be printed? (Maybe it is not in ISO 10646, maybe it is but there is no fonts, maybe the fonts is there but the rendering is wrong?) Since we are on the topic of the name badge, it is possible to somehow tag the family name of the person? (e.g. underline? bold? captialized?) Not everyone follows the convention. In fact, the concept of "First and Last" name is quite alien to me. -James Seng Dave Crocker wrote: Fred, FB> What I would suggest, if we do this, is writing the person's name *twice*: FB> once in their native character set, and once in a form that an FB> english-reader can read. The latter is an established interchange architecture I believe that was the intention in the proposal. List names in the same way we always have, AND list them in their "native" form. Whether it would helpful to provide a third form -- the ascii encoding of the native form, as it would be seen in an email address header -- is a separate question. /d -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA
Re: i18n name badges
On Wed, 19 Nov 2003 14:44:09 PST, "Ole J. Jacobsen" said: > line printers any more, but you get the idea :-) [If anyone still > remembers how to make a line printer attached to an IBM 370 do this by > sending just the right sort of code, you get extra points]. The IBM 1403 printer (1200 lines per minute, print chain and hammers) could be induced to do that fairly easily by specifying the right CCW (no, you couldn't do with with a Fortran-style column-1-char trick). You would however get extra points for figuring out how to get HASP to put the CCW into the spool file. It was pretty trivial under VM/CMS however http://www.columbia.edu/acis/history/1403.html (1403's could be induced to play music as well). The IBM 3800 (20K lpm laser printer) - now if you managed to get THAT beast to open its lid, that was impressive. http://ukcc.uky.edu/~ukccinfo/ibm3800.html pgp0.pgp Description: PGP signature
Re: [58crew] RE: IETF58 - Network Status
Iljitsch; I think there is some middle ground between 25000 and 10 ms. 10ms is the middle ground. That's enough for a bunch of retransmits on modern hardware. Retransmits on what type of hardware? At 1 Mbps transmitting a 1500 byte packet already takes 12 ms, without any link layer overhead, acks/naks or retransmits. End-to-end retransmits take even longer because of speed of light delays., That is a improper calculation. The requirement from TCP is that, on lightly loaded link, probability of packet drop should be very small. For example, if probability of collision is (despite CSMA/CA) 0.1, 2 retries will be enough to make packet drop probability 0.1%. If there are hidden terminals, probability of interference will get worse that more retry will be desired. And, with exponential back-off, delay will be doubled as the number of retries in increased by 1. Coupled with aggressive FEC, that's more than enough time. FEC sucks because it also eats away at usable bandwidth when there are no errors. Wrong reason. FEC is fine against thermal noise. However, FEC does not work at all here, because, with a collision, contents of colliding packets will be lost almost entirely. So let's: 1. Make sure access points don't have to contend with each other for airtime on the same channel 2. Make sure access points transmit with enough power to be heard over clients associated with other access points 3. Refrain from using too much bandwidth 4. Make use of higher-bandwidth wireless standards such as 802.11g No. 2 should be: Make sure clients and access points transmit with equal power to be heard over each other to enable CSMA/CA collision avoidance with random delay 1 is a performance improvement but is not a serious problem if CSMA/CA is working well. 3 is not specific to wireless and is irrelevant. 4 helps little but is not very meaningful as PPS, rather than BPS, is becoming the limiting factor, especially for applications with small packets such as VOIP. By the way, it would also be a good idea if the standard did proper power control of the mobile stations. Why? Raising the power output of the stuff you want to hear over these clients is much, much simpler. It is a good idea for some wireless protocol. However, it is the worst thing to do against CSMA/CA. Others won't notice your presence and won't reduce transmission rate. By the way, I did some testing today and the results both agree with and contradict conventional wisdom with regard to 802.11 channel utilization. When two sets of systems communicating over 802.11b/g are close together, they'll start interfering when the channels are 3 apart (ie, 5 and 8), slowing down data transfer significantly. This indicates that in the US only three channels can be used close together, but four in Europe: 1, 5, 9, 13. However, with the two sets of stations are NOT close together (but still well within range), such as with a wall in between them, 3 channels apart doesn't lead to statistically significant slowdowns, and even 2 channels apart is doable: 25% slowdown at 802.11b and 50% slowdown at 802.11g. So that would easily give us four usable channels in the US (1, 4, 8, 11) and 5 in Europe (1, 4, 7, 10, 13), or even six / seven (all odd channels) in a pinch. (As always, your milage may vary. These results were obtained with spare hardware lying around my house.) The results, it seems to me, completely agree with the conventional wisdom. Masataka Ohta
Re: i18n name badges
Fred, FB> What I would suggest, if we do this, is writing the person's name *twice*: FB> once in their native character set, and once in a form that an FB> english-reader can read. The latter is an established interchange architecture I believe that was the intention in the proposal. List names in the same way we always have, AND list them in their "native" form. Whether it would helpful to provide a third form -- the ascii encoding of the native form, as it would be seen in an email address header -- is a separate question. /d -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA
Re: i18n name badges
At 10:28 PM +0100 11/19/03, JORDI PALET MARTINEZ wrote: >It should be RFID, cheaper, and easier, not only for the blue sheets. > >The badge could be pre-configured with the data from our own IETF registration. > >The badge will store the names of the people who we have been talking during the >week, and data like when, how much time, We can then use an inexpensive reader >to get a small database out of it. > >Someone can complain about privacy issues, but I feel that is the same now when the >blue sheet is circulated, or the attendance list is in the web site, right ? > >It will save a lot of time (money) to all of us, including the IETF secretariat. > U ... take a look at http://ntag.com "nTAG Interactive provides a complete event communications system for forward-thinking business and social gatherings. The system is built around our groundbreaking interactive name badge - the nTAG. nTAGs are wearable computers that improve networking among event participants while streamlining event management..." _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ You can't depend on your judgement when your imagination is out of focus. -- Mark Twain. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ OLTECOAri Ollikainen P.O. BOX 20088Networking Architecture & Technology Stanford, CA [EMAIL PROTECTED] 94309-0088415.517.3519
Re: [58crew] RE: IETF58 - Network Status
Iljitsch van Beijnum <[EMAIL PROTECTED]> writes: > On 19-nov-03, at 23:16, Perry E.Metzger wrote: > >>> I think there is some middle ground between 25000 and 10 ms. > >> 10ms is the middle ground. That's enough for a bunch of retransmits on >> modern hardware. > > Retransmits on what type of hardware? At 1 Mbps transmitting a 1500 > byte packet already takes 12 ms, without any link layer overhead, > acks/naks or retransmits. Most of us are not running at that speed on 802.11b. Obviously if you're running at a lower speed adjustments should be made. > End-to-end retransmits take even longer because of speed of light delays., We're talking about to the base stations only. End to end is not the issue. The issue is 802.11 tries to be reliable to the base station, with disastrous results. >> Coupled with aggressive FEC, that's more than enough time. > > FEC sucks because it also eats away at usable bandwidth when there > are no errors. Having TCP collapse sucks too, because then no one can use the network. In any case, one can adjust the the armor to cope with the average bullet density. If the S/N is clean, you don't need as much FEC. >> If the network is so loaded that you can't send a packet in that >> period, you should drop so that all the TCPs back off. > > Absolutely not. Well, then, I'm sorry that you don't understand what happens to TCP under these circumstances, but some of the rest of us do. I was seeing packet traces showing clear signs of congestive collapse on the radio networks, and most of it was created by the packet warehousing our lovely 802.11 hardware believes it should do to "help" with the packet loss problems. It all reminded me horribly of the sorts of packet traces one saw on ARPANET and NYSERNET before VJ flow control became the norm. I really regret not saving packet traces. If I had known some people didn't understand congestion control I wouldn't thrown them away. Luckily, there is always the next conference. Perry
New list to discuss interaction of APPs and proposed Lower Layer Identifiers
Please see http://www.imc.org/ietf-aulli/index.html for info on joining; aulli will discuss how proposals like HIP, MAST, NoID, et al. will affect the Applications layer and end users. Ted Hardie
Re: Plans for IETF - 60
At 10:41 AM -0500 11/19/03, Brett Thorson wrote: I am hoping to get this done in time for IETF 59, but with current workload here at the IETF, I am going to aim for 60. Something else to add to the list: make software available for popular OS's that help the NOC team document the problems. For example, it would be grand if I could tell you which MAC just hijacked my network connection and turned it into a peer-to-peer connection. The software should be available for Win2K and later, as well as OS X. I suspect that the software is already available for Linux and BSD; all you need is instructions on which commands to use to get the data that is valuable to the NOC. --Paul Hoffman, Director --Internet Mail Consortium
Re: i18n name badges
>Someone can complain about privacy issues, but I feel that is the same now whe >n the blue sheet is circulated, or the attendance list is in the web site, rig >ht ? > Count me as one of the complainants. The big problem with RFID is that your identity is exposed at times when you don't want it to be. You can always decline to sign a blue sheet, or you can sign a fake name. As for the attendee list -- I don't recall if the IETF offers the option of not having your name listed; most other conferences I attend do provide that option, and the IETF should as well. --Steve Bellovin, http://www.research.att.com/~smb
Re: [58crew] RE: IETF58 - Network Status
On 19-nov-03, at 23:16, Perry E.Metzger wrote: I think there is some middle ground between 25000 and 10 ms. 10ms is the middle ground. That's enough for a bunch of retransmits on modern hardware. Retransmits on what type of hardware? At 1 Mbps transmitting a 1500 byte packet already takes 12 ms, without any link layer overhead, acks/naks or retransmits. End-to-end retransmits take even longer because of speed of light delays., Coupled with aggressive FEC, that's more than enough time. FEC sucks because it also eats away at usable bandwidth when there are no errors. But the problem with sharing the airwaves is that you can't be sure how long it's going to take to deliver packets. Actually, the speed of light is remarkably deterministic. Yes, but unfortunately, bit errors aren't. If the network is so loaded that you can't send a packet in that period, you should drop so that all the TCPs back off. Absolutely not. This leads to constant packet loss because of minor bursts, which TCP reacts very badly to. Try setting the output queues of your friendly neighborhood router to something extremely low and you'll see what I mean. The packet dumps I got from the 802.11b networks during the worst periods at IETF revealed what you would readily expect -- that TCP collapses badly when the underlying network does something very dumb. So let's: 1. Make sure access points don't have to contend with each other for airtime on the same channel 2. Make sure access points transmit with enough power to be heard over clients associated with other access points 3. Refrain from using too much bandwidth 4. Make use of higher-bandwidth wireless standards such as 802.11g By the way, it would also be a good idea if the standard did proper power control of the mobile stations. Why? Raising the power output of the stuff you want to hear over these clients is much, much simpler. Also, all of this makes it sound like the network was very bad in Minneapolis. That isn't my experience: I usually had good bandwidth, with the exception of just a couple of sessions, and I ended up associated with an ad-hoc network only a few times. By the way, I did some testing today and the results both agree with and contradict conventional wisdom with regard to 802.11 channel utilization. When two sets of systems communicating over 802.11b/g are close together, they'll start interfering when the channels are 3 apart (ie, 5 and 8), slowing down data transfer significantly. This indicates that in the US only three channels can be used close together, but four in Europe: 1, 5, 9, 13. However, with the two sets of stations are NOT close together (but still well within range), such as with a wall in between them, 3 channels apart doesn't lead to statistically significant slowdowns, and even 2 channels apart is doable: 25% slowdown at 802.11b and 50% slowdown at 802.11g. So that would easily give us four usable channels in the US (1, 4, 8, 11) and 5 in Europe (1, 4, 7, 10, 13), or even six / seven (all odd channels) in a pinch. (As always, your milage may vary. These results were obtained with spare hardware lying around my house.)
Re: IETF58 - Network Facts
On Wednesday, November 19, 2003, at 04:57 PM, Theodore Ts'o wrote: Would it be possible to publish a list of MAC addresses that were operating in ad-hoc or AP mode? I'll confess - it happened to me. 12" PowerBook running MacOS X 10.2.8. It was flipping into ad-hoc mode pretty much every time I tried to use the wireless network until I installed an updated Airport driver. Fortunately the menu bar icon shows a small icon of a computer in the middle of the Airport icon when it's in ad-hoc mode, so at least you can spot it when it happens, and fortunately there's a fix available. Melinda
Re: i18n name badges
If we do this, it should be WE (the IETF engineers) that do it and NOT another thing we request the secretariat to do. We should eat our own dogfood by writing, testing and then GIVING an implementation that is compatible with the current label making system to the secretariat. It's probably not too hard to do, given how the pre-reg badges are produced (I am guessing), but may be much harder for the on-site badges that are made using those little thermal printers. >From experience I can tell you that even adding the 3 extra characters we have in Scandinavian can cause all sorts of interesting problems when mixed with different output equipment. Add multi-byte characters and you may see line-printers shutting down and opening their lids indicating "paper out" or generating spurious form-feeds. OK, so we don't use line printers any more, but you get the idea :-) [If anyone still remembers how to make a line printer attached to an IBM 370 do this by sending just the right sort of code, you get extra points]. The good news is that modern operating systems (ahem) tend to have Unicode and other nice support built-in, but this doesn't necessarily mean that output is a breeze. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj -L here: On Wed, 19 Nov 2003, John C Klensin wrote: > --On Wednesday, November 19, 2003 11:15 -0800 Fred Baker > <[EMAIL PROTECTED]> wrote: > > > At 08:23 AM 11/19/2003, Peter Saint-Andre wrote: > >> Proposals for making email addresses fully internationalized > >> were a hot topic in Minneapolis. I'd like to suggest a more > >> modest reform: fully internationalized IETF name badges. > >> IETF 59 might be a fine venue for rolling those out... > > > > No problem, as long as nobody expects anyone in particular to > > actually be able to *read* the name badges. I don't read Han > > (simplified or traditional), Korean, Kanji, Cyrillic, Arab > > (either alphabet) or a variety of other alphabets. I manage > > with umlauts and such, because I can make a noise and the > > other person can say "yes, that's me, the way you pronounce my > > name is...". But I have no clue how to start in a > > non-ascii-like alphabet, and frankly with tonal languages such > > as Chinese my western mouth is likely to injure the person's > > name trying to get it out. > > > > Aside: I had a Taiwanese employee once who would periodically > > give me lessons on how to say her name. It sounded to *me* > > like I was pronouncing it her way. One can only wonder what > > she was hearing... > > > > Just speaking for myself, one of the things I really like > > about name badges is being able to determine, upon inspection, > > what to call the person standing in front of me. > > > > BTW, while I understand that many Asians can read each other's > > writing, I don't think that implies they can read Cyrillic or > > Arab either. They're in a similar boat, if not the same one. > > > > What I would suggest, if we do this, is writing the person's > > name *twice*: once in their native character set, and once in > > a form that an english-reader can read. The latter is an > > established interchange architecture. > > Fred, this is exactly what I was suggesting, only partially in > jest. Native character set, plus punycode, which is much more > precise than a transliteration. If we don't like the punycode > form, we probably need to think about what we are doing to > users in the absence of a serious presentation layer. > > john > >
Rf Id tag protocol
Anyone is interested to help me to write a protocol for the Rf ID? Thanks in advance giuseppe canale
Re: [58crew] RE: IETF58 - Network Status
Iljitsch van Beijnum <[EMAIL PROTECTED]> writes: > I think there is some middle ground between 25000 and 10 ms. 10ms is the middle ground. That's enough for a bunch of retransmits on modern hardware. Coupled with aggressive FEC, that's more than enough time. > But the problem with sharing the airwaves is that you can't be > sure how long it's going to take to deliver packets. Actually, the speed of light is remarkably deterministic. If the network is so loaded that you can't send a packet in that period, you should drop so that all the TCPs back off. > The difference between first try @ 11 Mbps and having to retry > several times @ 1 Mbps can easily be a factor 40. None the less, it ends up being much lower by orders of magnitude than what the standards currently permit. The packet dumps I got from the 802.11b networks during the worst periods at IETF revealed what you would readily expect -- that TCP collapses badly when the underlying network does something very dumb. By the way, it would also be a good idea if the standard did proper power control of the mobile stations. -- Perry E. Metzger[EMAIL PROTECTED]
Re: IETF58 - Network Facts
On Wed, Nov 19, 2003 at 11:26:30AM -0500, Brett Thorson wrote: > > 10% of the community using a wireless NIC was operating in ad-hoc or AP mode > at some point during the meeting. Would it be possible to publish a list of MAC addresses that were operating in ad-hoc or AP mode? If all of the happened to come from a signle manufacturer, that might be a very interesting data point. A public "hall of shame" might be very useful. If we do detect a pattern, perhaps a press release, "User friendly OS from company X disrupts Internet standards meeting" might get fast action to fix buggy implementations! > If these volunteers didn't step forward, there would be no network. > Double or triple the meeting fees, it wouldn't cover the cost of > > suitable replacements for the talented volunteers or the hardware on > temporary loan. I've run those numbers, those are the facts. And we definitely need to thank those volunteers! One question --- did we do a public acknowledgement of the terminal and network volunteers this time at the plenary? Maybe it happened on one of the days when I arrived late to the plenary, but if it didn't, let me express my thanks and kudos now. On a similar note, is there a way that we can better acknowledge the efforts who worked so hard? In addition, what kind of offers of help would be useful, as opposed to just Getting In The Way? Is it more bodies? More equipment? More diagnostic tools? - Ted
Re: i18n name badges
> I'm not sure if you are joking, but I think is an excellent idea ... > > A badge communication protocol ... if you start with the draft, I will > be happy to contribute ! I'm working on lots of other things, and somehow I suspect that others are more qualified than I am to get this rolling. The point is that both defining how this should work and writing proof-of-concept code are things that don't need to involve the secretariat. It makes more sense for the secretariat to take this on after we're sure we know what we want and it's been demonstrated to work well, than to impose another vaguely specified burden on a secretariat that is already quite busy. Keith
Re: i18n name badges
It should be RFID, cheaper, and easier, not only for the blue sheets. The badge could be pre-configured with the data from our own IETF registration. The badge will store the names of the people who we have been talking during the week, and data like when, how much time, We can then use an inexpensive reader to get a small database out of it. Someone can complain about privacy issues, but I feel that is the same now when the blue sheet is circulated, or the attendance list is in the web site, right ? It will save a lot of time (money) to all of us, including the IETF secretariat. Regards, Jordi - Original Message - From: "Rosen, Brian" <[EMAIL PROTECTED]> To: "'JORDI PALET MARTINEZ'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, November 19, 2003 10:14 PM Subject: RE: i18n name badges > Let's keep going. > > I'd contribute, say, $25, plus write some code towards getting a barcode > reader (or, maybe RFID??) for each meeting room that would be used to > "swipe in" and automate the "blue sheets". > > Brian > > > -Original Message- > > From: JORDI PALET MARTINEZ [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 19, 2003 3:08 PM > > To: [EMAIL PROTECTED] > > Subject: Re: i18n name badges > > > > > > Keith, > > > > I'm not sure if you are joking, but I think is an excellent idea ... > > > > A badge communication protocol ... if you start with the > > draft, I will be happy to contribute ! > > > > Regards, > > Jordi > > > > - Original Message - > > From: "Keith Moore" <[EMAIL PROTECTED]> > > To: "Peter Saint-Andre" <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > Sent: Wednesday, November 19, 2003 8:12 PM > > Subject: Re: i18n name badges > > > > > > > > Proposals for making email addresses fully > > internationalized were a > > > > hot topic in Minneapolis. I'd like to suggest a more > > modest reform: > > > > fully internationalized IETF name badges. IETF 59 might be a fine > > > > venue for rolling those out... > > > > > > I'd love to see an Internet-Draft on the topic. For > > instance, should > > > the badges be able to list multiple versions of a person's name and > > > affiliation? How many versions? > > > > > > That, and it seems appropriate to demonstrate running code. > > > Set up a web form where an attendee can type in his own names and > > > affiliations and have the backend generate a file to be printed out. > > > > > > > ** > > Madrid 2003 Global IPv6 Summit > > Presentations and videos on line at: > > http://www.ipv6-es.com > > > > This electronic message contains information which may be > > privileged or confidential. The information is intended to be > > for the use of the individual(s) named above. If you are not > > the intended recipient be aware that any disclosure, copying, > > distribution or use of the contents of this information, > > including attached files, is prohibited. > > > > > > > > > > ___ > > This message was passed through > > [EMAIL PROTECTED], which is a sublist of > > [EMAIL PROTECTED] Not all messages are passed. Decisions on what > > to pass are made solely by IETF_CENSORED ML Administrator > > ([EMAIL PROTECTED]). > > > ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
RE: i18n name badges
Let's keep going. I'd contribute, say, $25, plus write some code towards getting a barcode reader (or, maybe RFID??) for each meeting room that would be used to "swipe in" and automate the "blue sheets". Brian > -Original Message- > From: JORDI PALET MARTINEZ [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 19, 2003 3:08 PM > To: [EMAIL PROTECTED] > Subject: Re: i18n name badges > > > Keith, > > I'm not sure if you are joking, but I think is an excellent idea ... > > A badge communication protocol ... if you start with the > draft, I will be happy to contribute ! > > Regards, > Jordi > > - Original Message - > From: "Keith Moore" <[EMAIL PROTECTED]> > To: "Peter Saint-Andre" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Wednesday, November 19, 2003 8:12 PM > Subject: Re: i18n name badges > > > > > Proposals for making email addresses fully > internationalized were a > > > hot topic in Minneapolis. I'd like to suggest a more > modest reform: > > > fully internationalized IETF name badges. IETF 59 might be a fine > > > venue for rolling those out... > > > > I'd love to see an Internet-Draft on the topic. For > instance, should > > the badges be able to list multiple versions of a person's name and > > affiliation? How many versions? > > > > That, and it seems appropriate to demonstrate running code. > > Set up a web form where an attendee can type in his own names and > > affiliations and have the backend generate a file to be printed out. > > > > ** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be > privileged or confidential. The information is intended to be > for the use of the individual(s) named above. If you are not > the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, > including attached files, is prohibited. > > > > > ___ > This message was passed through > [EMAIL PROTECTED], which is a sublist of > [EMAIL PROTECTED] Not all messages are passed. Decisions on what > to pass are made solely by IETF_CENSORED ML Administrator > ([EMAIL PROTECTED]). >
Re: i18n name badges (Modified by Iljitsch van Beijnum)
On 19-nov-03, at 18:03, Dave Crocker wrote: I think that enhanced character sets is a perfect topic for having the IETF eat its own dogfood. Just dealing with the details of the name tags might well prove instructive to us, nevermind the basic politeness it offers to attendees. Easy to say for someone with an ASCII-only name... Not butchering the capitalization of my name would be nice, though. Илич van Beijnum PS. So is this the way to get around spamcontrol ? The instructions aren't very clear.
Re: [58crew] RE: IETF58 - Network Status
On 19-nov-03, at 17:45, Perry E.Metzger wrote: However, RED like approach to attempt retries only a few times may be a good strategy to improve latency. A RED approach would be good, 15 authors of RFC 2309 can't be wrong. :-) but in general there has to be a limit on the queue. Your wireless interface should not become a packet long term storage facility. I've seen RTTs to the base stations on the order of 25000ms (that's 25 SECONDS) or more. If you can't deliver a packet a through 300ns distance of air in 10ms, it is probably time to drop it. I think there is some middle ground between 25000 and 10 ms. While the former is definitely too long, the latter is probably too short. (Ignoring the fact that base stations may need to buffer packets for much longer than this when clients are in power save mode.) But the problem with sharing the airwaves is that you can't be sure how long it's going to take to deliver packets. The difference between first try @ 11 Mbps and having to retry several times @ 1 Mbps can easily be a factor 40. Last but not least, any system sitting between a high bandwidth link (100 Mbps ether) and a low bandwidth link (802.11b) needs to buffer to accommodate for the bursty nature of IP. Usually a round trip time worth of buffer memory is recommended. So that would be around 300 ms worth of 6 Mbps (= net throughput at 11 Mbps) = 220 kilobyte.
Re: i18n name badges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 JORDI PALET MARTINEZ wrote: | Keith, | | I'm not sure if you are joking, but I think is an excellent idea ... | | A badge communication protocol ... if you start with the draft, I will be happy to contribute ! | bcp? -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/u9QS8Jx8FtbMZncRAu81AJ9E8IxRHf43XOncGDDBwgoMf76QwgCgiKTH w8pdUOOrxFYy2juaXR5YAiM= =CBkj -END PGP SIGNATURE-
Re: i18n name badges
--On Wednesday, November 19, 2003 11:15 -0800 Fred Baker <[EMAIL PROTECTED]> wrote: > At 08:23 AM 11/19/2003, Peter Saint-Andre wrote: >> Proposals for making email addresses fully internationalized >> were a hot topic in Minneapolis. I'd like to suggest a more >> modest reform: fully internationalized IETF name badges. >> IETF 59 might be a fine venue for rolling those out... > > No problem, as long as nobody expects anyone in particular to > actually be able to *read* the name badges. I don't read Han > (simplified or traditional), Korean, Kanji, Cyrillic, Arab > (either alphabet) or a variety of other alphabets. I manage > with umlauts and such, because I can make a noise and the > other person can say "yes, that's me, the way you pronounce my > name is...". But I have no clue how to start in a > non-ascii-like alphabet, and frankly with tonal languages such > as Chinese my western mouth is likely to injure the person's > name trying to get it out. > > Aside: I had a Taiwanese employee once who would periodically > give me lessons on how to say her name. It sounded to *me* > like I was pronouncing it her way. One can only wonder what > she was hearing... > > Just speaking for myself, one of the things I really like > about name badges is being able to determine, upon inspection, > what to call the person standing in front of me. > > BTW, while I understand that many Asians can read each other's > writing, I don't think that implies they can read Cyrillic or > Arab either. They're in a similar boat, if not the same one. > > What I would suggest, if we do this, is writing the person's > name *twice*: once in their native character set, and once in > a form that an english-reader can read. The latter is an > established interchange architecture. Fred, this is exactly what I was suggesting, only partially in jest. Native character set, plus punycode, which is much more precise than a transliteration. If we don't like the punycode form, we probably need to think about what we are doing to users in the absence of a serious presentation layer. john
Re: i18n name badges
Keith, I'm not sure if you are joking, but I think is an excellent idea ... A badge communication protocol ... if you start with the draft, I will be happy to contribute ! Regards, Jordi - Original Message - From: "Keith Moore" <[EMAIL PROTECTED]> To: "Peter Saint-Andre" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, November 19, 2003 8:12 PM Subject: Re: i18n name badges > > Proposals for making email addresses fully internationalized were a > > hot topic in Minneapolis. I'd like to suggest a more modest reform: > > fully internationalized IETF name badges. IETF 59 might be a fine > > venue for rolling those out... > > I'd love to see an Internet-Draft on the topic. For instance, should > the badges be able to list multiple versions of a person's name and > affiliation? How many versions? > > That, and it seems appropriate to demonstrate running code. > Set up a web form where an attendee can type in his own names and > affiliations and have the backend generate a file to be printed out. > ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: i18n name badges
At 08:23 AM 11/19/2003, Peter Saint-Andre wrote: Proposals for making email addresses fully internationalized were a hot topic in Minneapolis. I'd like to suggest a more modest reform: fully internationalized IETF name badges. IETF 59 might be a fine venue for rolling those out... No problem, as long as nobody expects anyone in particular to actually be able to *read* the name badges. I don't read Han (simplified or traditional), Korean, Kanji, Cyrillic, Arab (either alphabet) or a variety of other alphabets. I manage with umlauts and such, because I can make a noise and the other person can say "yes, that's me, the way you pronounce my name is...". But I have no clue how to start in a non-ascii-like alphabet, and frankly with tonal languages such as Chinese my western mouth is likely to injure the person's name trying to get it out. Aside: I had a Taiwanese employee once who would periodically give me lessons on how to say her name. It sounded to *me* like I was pronouncing it her way. One can only wonder what she was hearing... Just speaking for myself, one of the things I really like about name badges is being able to determine, upon inspection, what to call the person standing in front of me. BTW, while I understand that many Asians can read each other's writing, I don't think that implies they can read Cyrillic or Arab either. They're in a similar boat, if not the same one. What I would suggest, if we do this, is writing the person's name *twice*: once in their native character set, and once in a form that an english-reader can read. The latter is an established interchange architecture.
Re: [58crew] RE: IETF58 - Network Status
Perry; Because of exponential backoff, aggregated bandwidth of multiple TCP over congested WLAN should not be so bad. However, RED like approach to attempt retries only a few times may be a good strategy to improve latency. A RED approach would be good, but in general there has to be a limit on the queue. Your wireless interface should not become a packet long term storage facility. We are saying the same thing. I've seen RTTs to the base stations on the order of 25000ms (that's 25 SECONDS) or more. If you can't deliver a packet a through 300ns distance of air in 10ms, it is probably time to drop it. With exponential back-off with base 2, 10ms of initial delay becomes 40s after 12 attempts of retry. Note that 25000ms of delay does not necessarily mean that a station has a large buffer. Masataka Ohta
Re: i18n name badges
> Proposals for making email addresses fully internationalized were a > hot topic in Minneapolis. I'd like to suggest a more modest reform: > fully internationalized IETF name badges. IETF 59 might be a fine > venue for rolling those out... I'd love to see an Internet-Draft on the topic. For instance, should the badges be able to list multiple versions of a person's name and affiliation? How many versions? That, and it seems appropriate to demonstrate running code. Set up a web form where an attendee can type in his own names and affiliations and have the backend generate a file to be printed out.
Re: i18n name badges
There is a better solution. I've seen already IPv6 enabled badges ! We used it in one of the IPv6 Forum conferences ... last June in San Diego. - Original Message - From: "John C Klensin" <[EMAIL PROTECTED]> To: "Dave Crocker" <[EMAIL PROTECTED]>; "Peter Saint-Andre" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, November 19, 2003 7:07 PM Subject: Re: i18n name badges > > > --On Wednesday, November 19, 2003 09:03 -0800 Dave Crocker > <[EMAIL PROTECTED]> wrote: > > > Peter, > > > > PSA> Proposals for making email addresses fully > > internationalized were a hot PSA> topic in Minneapolis. I'd > > like to suggest a more modest reform: fully PSA> > > internationalized IETF name badges. IETF 59 might be a fine > > venue for PSA> rolling those out... > > > > > > I think that enhanced character sets is a perfect topic for > > having the IETF eat its own dogfood. Just dealing with the > > details of the name tags might well prove instructive to us, > > nevermind the basic politeness it offers to attendees. > > If we are really going to eat our own dogfood, we should also > (or exclusively) print punycode on the badges and then everyone > can carry a ToUnicode converter on his or her laptop or PDA :-( > > john > ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: IETF58 - Network Status
I don't think so, sorry. The network setup is not different (it should not be), if we have a host or not. I'm convinced the secretariat has the expertise to do it well. We have been in the same hotel other times, and it worked fine. We just need to discover exactly what happened, and most probably comparing with Vienna could be a good way to attack the problems ! Also, there are still few companies willing to host IETF. I've offered Madrid (Spain) since 2.5 years ago ... the process is very slow. The secretariat already visited the hotel, and they agreed that is a very good installation, if I'm not wrong, their words were "excellent, one of the best properties that we never seen" (actually the bigger hotel in Europe), and it already has Ethernet (with IPv6, for free) in every guest room. The network is ready in every meeting room, in the corridors, ... We have already organized big events there. The issue, according to what I talked last week with the Secretariat and Harald (just a very few minutes), is that the hotel is not located downtown, but just in front of the airport, and they argue the transport isn't good. I can tell that there is no metro, right, but there are 4 bus lines in the door, a free shuttle to the airport (then metro 12 minutes to the center of the city), and I offered also a free shuttle service to downtown. Even more, a taxi either to the metro or to downtown will cost less than 4-5 Euros (what about sharing it among different participants). I don't see the problem, but of course I'm local and know it very well. My proposal also included a social, and may be a change in the schedule of the meetings. Trying to lunch downtown at 11:30 is impossible (of course no problem if in the hotel), or even to dinner at 17:30, so I suggested trying to adapt the agenda to the local timing, have a kind of "extended coffee break" or snack before the last meeting (i.e. plenary), then have dinner after, starting at 20:30-21:00. And I know the cost of the IETF in Madrid will be probably one of the cheaper ... and hopefully very well attended. Anyway, the target was 2004, but now is too late. I'm preparing a short report to try to convince Harald and whoever needs to be convinced and I will be happy to circulate it in this list. Now I already offered Madrid for 2005, and 1.5-2 years later in Barcelona. But unless we react soon, the hotel pre-booking that I did, will go for 2005 also. But of course, my offer can't last for ever. Actually is costing me more time and effort to convince the IETF to come here, than probably setup it, even with a good network ;-) Regards, Jordi - Original Message - From: "Kevin C. Almeroth" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, November 19, 2003 6:21 PM Subject: Re: IETF58 - Network Status > >>As for the network: Vienna has shown that it's possible to do better. > >>At the same time, with 1000+ people in a room performance isn't going > >>to be great. Poor network performance during plenaries and other > >>crowded sessions isn't the end of the world as long as the network > >>functions well elsewhere. > > It might be a good idea to stop comparing Minneapolis to Vienna. Vienna > had a host and Minneapolis did not. > > Having a host is a good thing but few companies are willing to step > forward anymore. Solve that problem and many other problems get > solved... including more important ones like having a T-shirt. > > -kevin > ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: i18n name badges
--On Wednesday, November 19, 2003 09:03 -0800 Dave Crocker <[EMAIL PROTECTED]> wrote: > Peter, > > PSA> Proposals for making email addresses fully > internationalized were a hot PSA> topic in Minneapolis. I'd > like to suggest a more modest reform: fully PSA> > internationalized IETF name badges. IETF 59 might be a fine > venue for PSA> rolling those out... > > > I think that enhanced character sets is a perfect topic for > having the IETF eat its own dogfood. Just dealing with the > details of the name tags might well prove instructive to us, > nevermind the basic politeness it offers to attendees. If we are really going to eat our own dogfood, we should also (or exclusively) print punycode on the badges and then everyone can carry a ToUnicode converter on his or her laptop or PDA :-( john
Re: IETF58 - Network Status
On Wed, Nov 19, 2003 at 09:21:59AM -0800, Kevin C. Almeroth wrote: > > It might be a good idea to stop comparing Minneapolis to Vienna. Vienna > had a host and Minneapolis did not. And a host that did not document what it did for the WLAN provision, despute requests to do so. Tim
Re: IETF58 - Network Status
On Wed, 19 Nov 2003, Kevin C. Almeroth wrote: > >>On Wed, 19 Nov 2003, Iljitsch van Beijnum wrote: > >>> > >>> As long as we're bitching about the network: would it be possible to > >>> start doing some unicast streaming of sessions in the future? Access to > >>> multicast hasn't gotten significantly better the past decade, but > >>> streaming over unicast is now routine as the codecs are so much better > >>> these days, as is typical access bandwidth. I'll happily take 40 kbps > >>> MPEG-4 audio only; the video is so badly out of sync that it is > >>> unwatchable most of the time anyway. > >> > >>if you want to show up with encoders I'll give you an audio/video feed... > >>then you can baby your boxes and not go to any meeting you want all week > >>just like me. I would be able lot cheaper and less work if the multicast > >>folks just paid to go to the meeting like normal people. > > Actually, I'm not even sure I agree with this. The reason is because if > we had more than a handful of people watching remotely, it would add quite > a bit of congestion to the network link. > > So, if you are willing to be sent a unicast stream and then provide the > bandwidth to replicate it to everyone else in the world who wants it by > unicast, then I think we have a doable solution. I'm sorry I sort of assumed that would be necessary for anything beyond minimal bitrates... We source around 6Mb/s from the ietf, even the sources we reflect to other multicast streams (like the ssm sources) we do from some location off of the conference network, such as the UO. > -kevin > -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: IETF58 - Network Status
>>On Wed, 19 Nov 2003, Iljitsch van Beijnum wrote: >>> >>> As long as we're bitching about the network: would it be possible to >>> start doing some unicast streaming of sessions in the future? Access to >>> multicast hasn't gotten significantly better the past decade, but >>> streaming over unicast is now routine as the codecs are so much better >>> these days, as is typical access bandwidth. I'll happily take 40 kbps >>> MPEG-4 audio only; the video is so badly out of sync that it is >>> unwatchable most of the time anyway. >> >>if you want to show up with encoders I'll give you an audio/video feed... >>then you can baby your boxes and not go to any meeting you want all week >>just like me. I would be able lot cheaper and less work if the multicast >>folks just paid to go to the meeting like normal people. Actually, I'm not even sure I agree with this. The reason is because if we had more than a handful of people watching remotely, it would add quite a bit of congestion to the network link. So, if you are willing to be sent a unicast stream and then provide the bandwidth to replicate it to everyone else in the world who wants it by unicast, then I think we have a doable solution. -kevin
Re: IETF58 - Network Status
>>As for the network: Vienna has shown that it's possible to do better. >>At the same time, with 1000+ people in a room performance isn't going >>to be great. Poor network performance during plenaries and other >>crowded sessions isn't the end of the world as long as the network >>functions well elsewhere. It might be a good idea to stop comparing Minneapolis to Vienna. Vienna had a host and Minneapolis did not. Having a host is a good thing but few companies are willing to step forward anymore. Solve that problem and many other problems get solved... including more important ones like having a T-shirt. -kevin
Re: i18n name badges
Peter, PSA> Proposals for making email addresses fully internationalized were a hot PSA> topic in Minneapolis. I'd like to suggest a more modest reform: fully PSA> internationalized IETF name badges. IETF 59 might be a fine venue for PSA> rolling those out... I think that enhanced character sets is a perfect topic for having the IETF eat its own dogfood. Just dealing with the details of the name tags might well prove instructive to us, nevermind the basic politeness it offers to attendees. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA
Re: [58crew] RE: IETF58 - Network Status
Masataka Ohta <[EMAIL PROTECTED]> writes: > Because of exponential backoff, aggregated bandwidth of multiple TCP > over congested WLAN should not be so bad. > > However, RED like approach to attempt retries only a few times may be > a good strategy to improve latency. A RED approach would be good, but in general there has to be a limit on the queue. Your wireless interface should not become a packet long term storage facility. I've seen RTTs to the base stations on the order of 25000ms (that's 25 SECONDS) or more. If you can't deliver a packet a through 300ns distance of air in 10ms, it is probably time to drop it. Perry
Re: report on the wlan difficulties in IETF?
Brett Thorson wrote: Jari, I will be working on a summary document that pulls together the technical items we witnessed at the meeting. Great, thanks! Also, I'd like to take this opportunity to thank you and the rest of the folks who set up the networks for our meetings. The networks have worked extremely well. Yes, we had problems this time but I don't think it was your fault. If we find out why, it may even improve the protocols. Much of this is volunteer work, and we need to respect the folks who do it. So lets not complain about the network difficulties, lets work to resolve them. And volunteer to help next time... --Jari
IETF58 - Network Facts
I am still collecting data from the IETF 58 network, when I can state additional facts I will post them along this thread. Until then, here are some facts that correct messages posted previously. All wireless access points were set at 1 milliwatt on channel 6 when they were first deployed. On and after Monday these value were changed. We did not run all access points on 1 milliwatt on channel 6 beyond Sunday night. 10% of the community using a wireless NIC was operating in ad-hoc or AP mode at some point during the meeting. I noticed many people in the terminal room using a hard wire connection. When I did a non-scientific survey of a sample of these users, they did not have a wireless card at all. Cost of the terminal room is not appropriate here. If these volunteers didn't step forward, there would be no network. Double or triple the meeting fees, it wouldn't cover the cost of suitable replacements for the talented volunteers or the hardware on temporary loan. I've run those numbers, those are the facts. ---In other news-- (Think Red Cross, don't think Power Company) I had six people come up to me on Thursday to let me know that their wireless connection was acceptable (they used words like great, and no problems). I hope that more people would take the time to document their positive experiences. This will give us more perspective on the total experience and it is the only payment these volunteers get from this community. At this point, we know the issues, we know the complaints. Right now, it would be nice to hear where the network did work, and some positive comments. A message to [EMAIL PROTECTED] would be great. I am going silent on this list for a while, don't want to stir things up too much. Responses will be made privately if warranted. --Brett
i18n name badges
Proposals for making email addresses fully internationalized were a hot topic in Minneapolis. I'd like to suggest a more modest reform: fully internationalized IETF name badges. IETF 59 might be a fine venue for rolling those out... Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.php
Re: report on the wlan difficulties in IETF?
In message <[EMAIL PROTECTED]>, "Theodore Ts'o" writes: > >It might be interesting to let the 802.11i folks see what life with >unathenticated radio beacons is really like. :-) You mean invite them to SAAG and tell the obvious people that it's open season? Nasty --Steve Bellovin, http://www.research.att.com/~smb
Re: report on the wlan difficulties in IETF?
At 08:15 AM 11/19/2003, Jari Arkko wrote... >Say, its pretty useless to authenticate beacons if >the radios are simply swamped by too many nodes who think they are >access points This is not a technical issue. By taking advantage of unlicensed frequencies, 802.1a/b/g must not cause interference with licensed services, and must accept interference from other users, at least in the US. There really is no basis for any complaint of lack of service due to interference from any other WLAN or ISM device/user. If you desire a somewhat assured RF medium, explored using licensed frequencies, but then you'll have to live with other restraints. Mike
Plans for IETF - 60
I am hoping to get this done in time for IETF 59, but with current workload here at the IETF, I am going to aim for 60. 1) Make a form used for meetings where people can submit wireless reports. Require certain data be submitted (Location, computer, NIC, user) 2) Make a form where people can submit end of meeting wireless opinions. One opinion to an attendee. 3) Write up a new terminal room / IETF MeetNet document. When I am ready to accept public input & review regarding these documents, I will post a message. Thanks. --Brett
Re: report on the wlan difficulties in IETF?
Jari, I will be working on a summary document that pulls together the technical items we witnessed at the meeting. --Brett On Wednesday 19 November 2003 08:15, Jari Arkko wrote: > Hello, > > I wonder if anyone has documented the situation of the IETF wireless > network and analyzed the experienced difficulties? I'd be interested > in looking at the causes of the difficulties. There's a lot of anecdotal > information about the capabilities of the protocols and advice on what > to do on this list. But it would be good to know what was the real cause > of difficulties. Say, its pretty useless to authenticate beacons if > the radios are simply swamped by too many nodes who think they are > access points. Similarly, access control a la 802.1X does not help > if the interferences are caused during or before access authentication > has taken place. Or a correctly operating radio network is no good if > all of its capacity is used by the legitimate, but infected, hosts > for something non-productive. The bottom line is that finger pointing > (staff, ieee, fcc, ourselves...), if useful at all, should come after we > find out what happened. > > I suspect the IETF network is pretty the worst case scenario for > current wireless LANs (or can someone point an even more demanding > case?). But what we do today will be done tomorrow by regular users... > > --Jari
Re: report on the wlan difficulties in IETF?
Just as a whimsical notion would it be possible to, ah, invite some of the 802.11* wireless committees to have a colocated meeting with the IETF at some point in the future? We could dangle the offer of "free" wireless networking, plus an offer for them to see what a real-life, large-scale deployment wireless is really like. Give them a chance for them to eat their own dog-food. It might be interesting to let the 802.11i folks see what life with unathenticated radio beacons is really like. :-) - Ted
report on the wlan difficulties in IETF?
Hello, I wonder if anyone has documented the situation of the IETF wireless network and analyzed the experienced difficulties? I'd be interested in looking at the causes of the difficulties. There's a lot of anecdotal information about the capabilities of the protocols and advice on what to do on this list. But it would be good to know what was the real cause of difficulties. Say, its pretty useless to authenticate beacons if the radios are simply swamped by too many nodes who think they are access points. Similarly, access control a la 802.1X does not help if the interferences are caused during or before access authentication has taken place. Or a correctly operating radio network is no good if all of its capacity is used by the legitimate, but infected, hosts for something non-productive. The bottom line is that finger pointing (staff, ieee, fcc, ourselves...), if useful at all, should come after we find out what happened. I suspect the IETF network is pretty the worst case scenario for current wireless LANs (or can someone point an even more demanding case?). But what we do today will be done tomorrow by regular users... --Jari
