From saurabhk@usc.edu Sat May 3 20:25:31 2003 From: saurabhk@usc.edu (saurabh khurana) Date: Sat, 03 May 2003 12:25:31 -0700 Subject: [Csci551-talk] lecture 15 slides Message-ID: Hi, i was wondering when will the slides and lecture notes for lecture 15 be made available on the web page ? Thanks saurabh From rajgarhi@usc.edu Sat May 3 20:34:12 2003 From: rajgarhi@usc.edu (abhishek rajgarhia) Date: Sat, 03 May 2003 12:34:12 -0700 Subject: [Csci551-talk] Hw3 Message-ID: Hi, With regard to Q1 in hw3, do we have to give reasons for use of crypographic hashes which are specific to Freenet, or can we give general reasons for the use of cryprographic hashes by p2p applications.. Thanks Regards Abhishek From xiw@usc.edu Sun May 4 00:14:32 2003 From: xiw@usc.edu (Xi Wang) Date: Sat, 03 May 2003 16:14:32 -0700 Subject: [Csci551-talk] hw3 tag not valid Message-ID: <008e01c311c9$c2689b80$f1de7d80@xwl3> Hi. I tried to submit using "..-tag hw3" but it is not valid. (The assignment indicated "..-tag hw1".) Thanks, Xi From johnh@ISI.EDU Sun May 4 00:04:36 2003 From: johnh@ISI.EDU (John Heidemann) Date: Sat, 03 May 2003 16:04:36 -0700 Subject: [Csci551-talk] Hw3 In-Reply-To: Message-ID: <200305032305.h43N4a2a015526@dash.isi.edu> On Sat, 03 May 2003 12:34:12 PDT, abhishek rajgarhia wrote: >Hi, > >With regard to Q1 in hw3, do we have to give reasons for use of crypographic hashes which are specific to Freenet, or can we give general reasons for the use of cryprographic hashes by p2p applications.. > > >Thanks > >Regards > >Abhishek The question is about Freenet, but you may find it helpful to refer to other systems to justify your answer. -John Heidemann From gnawali@usc.edu Sun May 4 01:43:54 2003 From: gnawali@usc.edu (Omprakash Gnawali) Date: Sat, 03 May 2003 17:43:54 -0700 Subject: [Csci551-talk] hw3 tag not valid In-Reply-To: Your message of Sat, 03 May 2003 16:14:32 -0700 Message-ID: <200305040043.h440hsm5015387@enl.usc.edu> Thanks for pointing out the bug. It should be fixed now. The tag is "hw3". you wrote: > Hi. I tried to submit using "..-tag hw3" but it is not valid. (The > assignment indicated "..-tag hw1".) > > Thanks, > > Xi From johnh@ISI.EDU Mon May 5 02:17:54 2003 From: johnh@ISI.EDU (John Heidemann) Date: Sun, 04 May 2003 18:17:54 -0700 Subject: [Csci551-talk] lecture 15 slides In-Reply-To: Message-ID: <200305050117.h451HtjM003806@dash.isi.edu> On Sat, 03 May 2003 12:25:31 PDT, saurabh khurana wrote: >Hi, >i was wondering when will the slides and lecture notes for lecture 15 be made available on the web page ? >Thanks >saurabh They have now been posted. -John Heidemann From gnawali@usc.edu Tue May 6 02:16:58 2003 From: gnawali@usc.edu (Omprakash Gnawali) Date: Mon, 05 May 2003 18:16:58 -0700 Subject: [Csci551-talk] TA not available Message-ID: <200305060116.h461GwIp009104@enl.usc.edu> This is Om's friend sending email on his behalf. Om is recovering from snow blindness and the latest estimate is he will start seeing again Tuesday night. Till then, please bear with him. From phadke@usc.edu Tue May 6 04:40:40 2003 From: phadke@usc.edu (amol-uday phadke) Date: Mon, 05 May 2003 20:40:40 -0700 Subject: [Csci551-talk] projb grades Message-ID: <13ea00713e3e1a.13e3e1a13ea007@usc.edu> Hi I will be mailing out the grades for projb in the next one hour. We will also post (by tonite or tomorrow morning) the test cases I used to grade with the expected outputs so that you can go over them and see the errors. Thanks ..Amol. From gnawali@usc.edu Wed May 7 06:28:24 2003 From: gnawali@usc.edu (Omprakash Gnawali) Date: Tue, 06 May 2003 22:28:24 -0700 Subject: [Csci551-talk] hw3 receipt email Message-ID: <200305070528.h475SOiP023086@enl.usc.edu> I sent an email to everyone who submitted hw3. If you did not receive this email, you need to contact me as soon as possible. If you sent me an email in the last few days and if you don't get a response by the end of the day tomorrow, please send that email to me again. Thanks. From gnawali@usc.edu Wed May 7 06:52:02 2003 From: gnawali@usc.edu (Omprakash Gnawali) Date: Tue, 06 May 2003 22:52:02 -0700 Subject: [Csci551-talk] HW3 slip day request acknowledgement Message-ID: <200305070552.h475q297023834@enl.usc.edu> I just sent out emails to all the students who asked for slip days for HW3. If you asked for a slip day but didn't get an email confirmation, please let me know as soon as possible. Thanks. From johnh@ISI.EDU Thu May 8 19:47:11 2003 From: johnh@ISI.EDU (John Heidemann) Date: Thu, 08 May 2003 11:47:11 -0700 Subject: [Csci551-talk] csci551: homework keys and notes about the final Message-ID: <200305081847.h48IlBfJ005113@dash.isi.edu> First, the keys for homeworks 2 and 3 have been posted. Second there will be one new thing about the mechanics of the final. Three of the questions are labeled ``hint for sale''. These questions might be a bit harder than some other questions. Think about them, but if you're not sure where to get started, you can _purchase a hint_. A hint will cost you some points---you will only get partial credit on the question, not full credit, and you will only get partial credit if the hint enables you to figure out the other parts of the question. However, if you're not sure where to start, partial credit might be better than zero credit. (Having a hint won't gurantee that you get the answer, but it can perhaps get you started.) To purchase a hint during the exam, raise your hand and when the proctor arrives, indicate the question number. The proctor will mark that problem as hint taken. You can then write down your answer for the question. If you get the answer correct, the indicated number of points will be deducted. If you do not get the answer correct, there will be no penalty. Basically, if you ignore the hints and answer the questions, they can't hurt you. If you can't answer the question at all, you might want to ask for the hint and see if it helps you out. If it doesn't help you, you're no worse off. If it does help you, you should get more credit than you would have if you were completely stuck. If you have any questions about buying hints on the final, please ask me in e-mail or before (or during) the exam. -John Heidemann From shshanks@usc.edu Thu May 8 20:44:19 2003 From: shshanks@usc.edu (Shshank Sharma) Date: Thu, 8 May 2003 12:44:19 -0700 Subject: [Csci551-talk] csci551: homework keys and notes about the final In-Reply-To: <200305081847.h48IlBfJ005113@dash.isi.edu> Message-ID: > First, the keys for homeworks 2 and 3 have been posted. Homework 2: re: questions 2g and 2h: Collsions _are_ observed if we keep the seperation between the left and right nodes to be less than or equal to 250m (surprisingly exact). Beyond this separation, collisions are not observed. The assignment statement does not mention actual distances, so I feel the correct answer needs to capture both scenarios, or perhaps both a *no collision* or a *collision* answer can be correct depending on the distance at which the experiment was performed. Perhaps the TA or the Professor can clarify this. re: question 2e and 2f: Since the right node can barely hear the center node, it is possible that it will _not_ hear a CTS meant to indicate that a left-center data transfer is impending. So, that means that it (the right node) can send at a _wrong_ time, thereby causing intereference, though this will happen rarely. I thought there will be _occasional_ interference. Something I missed ? Homework 3 re: question 1c: Does computational overhead in case of large, frequently changing files, speak against content-hashing ? -Sharma From pande@usc.edu Fri May 9 00:56:41 2003 From: pande@usc.edu (mohit pande) Date: Thu, 08 May 2003 16:56:41 -0700 Subject: [Csci551-talk] csci551: homework keys and notes about the final Message-ID: <5db2a57101.571015db2a@usc.edu>

> > First, the keys for homeworks 2 and 3 have been posted.
>
> Homework 2:
>
> re: questions 2g and 2h:
> Collsions _are_ observed if we keep the seperation between the left and
> right nodes to be less than or equal to 250m (surprisingly exact). Beyond
> this separation, collisions are not observed. The assignment statement does
> not mention actual distances, so I feel the correct answer needs to capture
> both scenarios, or perhaps both a *no collision* or a *collision* answer can
> be correct depending on the distance at which the experiment was performed.
> Perhaps the TA or the Professor can clarify this.
>
The collisions that are observed are the RTS collisions and not data collisions (evident from the trace). The hw question did not specify which "type of pkt" drop.

But i do believe that the hw key should have taken this into account and not just data pkt drop.

Also, I hope the grader has seen the trace samples I have included in the answer and taken the above reasoning (about the type of pkts) into account.

mohit

From gnawali@usc.edu Fri May 9 02:59:26 2003 From: gnawali@usc.edu (Omprakash Gnawali) Date: Thu, 08 May 2003 18:59:26 -0700 Subject: [Csci551-talk] hw2 grade Message-ID: <200305090159.h491xQ6k014746@enl.usc.edu> I just sent HW2 grades. If you didn't receive it, you should let me know soon. From nimeshmshah@hotmail.com Fri May 9 03:29:42 2003 From: nimeshmshah@hotmail.com (nimesh shah-alias-nagda) Date: Thu, 08 May 2003 19:29:42 -0700 Subject: [Csci551-talk] What are the average scores for project A, project B and hw2? Message-ID: Nimesh M Shah 1223A West Adams LA, CA 90007 From johnh@ISI.EDU Sat May 10 20:18:12 2003 From: johnh@ISI.EDU (John Heidemann) Date: Sat, 10 May 2003 12:18:12 -0700 Subject: [Csci551-talk] csci551: homework keys and notes about the final In-Reply-To: Message-ID: <200305101918.h4AJICZu010737@dash.isi.edu> On Thu, 08 May 2003 12:44:19 PDT, "Shshank Sharma" wrote: >Homework 3 >re: question 1c: >Does computational overhead in case of large, frequently changing files, >speak against content-hashing ? Perhaps. Can you suggest any large files that are frequently changing and stored in a p2p system? I can think of large, frequently changing files that are not stored in a p2p system. And I can think of large, basically unchanging files that ARE stored in a p2p system. But I have a hard time thinking of examples that have all of those characteristics. -John Heidemann From johnh@ISI.EDU Sat May 10 20:29:05 2003 From: johnh@ISI.EDU (John Heidemann) Date: Sat, 10 May 2003 12:29:05 -0700 Subject: [Csci551-talk] csci551: homework keys and notes about the final In-Reply-To: <5db2a57101.571015db2a@usc.edu> Message-ID: <200305101929.h4AJT5Jg010955@dash.isi.edu> On Thu, 08 May 2003 16:56:41 PDT, mohit pande wrote: > >> > First, the keys for homeworks 2 and 3 have been posted. >> >> Homework 2: >> >> re: questions 2g and 2h: >> Collsions _are_ observed if we keep the seperation between the left and >> right nodes to be less than or equal to 250m (surprisingly exact). Beyond >> this separation, collisions are not observed. The assignment statement does >> not mention actual distances, so I feel the correct answer needs to capture >> both scenarios, or perhaps both a *no collision* or a *collision* answer can >> be correct depending on the distance at which the experiment was performed. >> Perhaps the TA or the Professor can clarify this. >> >The collisions that are observed are the RTS collisions and not data >collisions (evident from the trace). The hw question did not specify which >"type of pkt" drop. > >But i do believe that the hw key should have taken this into account and not >just data pkt drop. > >Also, I hope the grader has seen the trace samples I have included in the >answer and taken the above reasoning (about the type of pkts) into account. While the key did not reflect this, the grading did. -John Heidemann From shshanks@aludra.usc.edu Sun May 11 04:26:13 2003 From: shshanks@aludra.usc.edu (Shshank Sharma) Date: Sat, 10 May 2003 20:26:13 -0700 (PDT) Subject: [Csci551-talk] content-hashing in p2p nets In-Reply-To: <200305101918.h4AJICZu010737@dash.isi.edu> Message-ID: > >Does computational overhead in case of large, frequently changing files, > >speak against content-hashing ? > > Perhaps. Can you suggest any large files that are frequently changing > and stored in a p2p system? > > I can think of large, frequently changing files that are not stored in > a p2p system. And I can think of large, basically unchanging files > that ARE stored in a p2p system. But I have a hard time thinking of > examples that have all of those characteristics. > ::Sigh:: Confession: I was thinking quite mechanically, just looking for what would be _bad_ for content-hashing, rather than practically. A node on a p2p net, that apart from allowing uploads from its local disk, also does the server-like job of logging all incoming requests (say source IPs or some such), for offline processing could lead to a large, changing-often file stored on it. The typical kind of files stored today in p2p nets (mp3, video) are ofcourse large and unchanging, but what would prevent large, changing-often files from being stored in a p2p net ? -Shshank Sharma From gnawali@usc.edu Mon May 12 21:53:50 2003 From: gnawali@usc.edu (Omprakash Gnawali) Date: Mon, 12 May 2003 13:53:50 -0700 Subject: [Csci551-talk] hw3 grades Message-ID: <200305122053.h4CKrorH018433@enl.usc.edu> I just sent out grades for hw3. If you are not happy with the grades for some reason it might be the best for you to contact me before tomorrow so that we can resolve your concerns before we assign letter grades. Here are some comments on answers I read in hw3: * Computation overhead for computing content hash is not high. You can compute hash for a 100MB file in a few seconds at most. Now compare this to the time it takes to upload this file to the network. * Some students did not describe if they meant security or privacy while arguing about hashes and encryption. Some students mentioned content hash providing authenticity for the file. Content hashes are self-certifying so they provide integrity check (not authenticity). * Using hashes does not provide anonymity. Anonymity by obscurity is frowned upon in the security community. * Using hashes for names does not imply anything about whether or not the content is encrypted. * Using indecipherable names (hashes) does not help in deniability because content can be readily analyzed as long as it is encrypted. * Lexicographically clustering the routing tables is possible without using hash keys. One can sort the descriptive names and partition the alphabet space into different blocks for different links/nodes. This is exactly the same thing one would do when routing based on hash keys. * Most students did not describe why the metrics matter to ad-hoc routing in particular. Just making an argument about efficiency does not make answer specific to ad-hoc platform. I was expecting the students to make an argument about specific constraints in ad-hoc environment that make those metric important. From gnawali@usc.edu Thu May 15 03:03:52 2003 From: gnawali@usc.edu (Omprakash Gnawali) Date: Wed, 14 May 2003 19:03:52 -0700 Subject: [Csci551-talk] content-hashing in p2p nets In-Reply-To: Your message of Sat, 10 May 2003 20:26:13 -0700 (PDT) Message-ID: <200305150203.h4F23qSD017279@enl.usc.edu> For that application, rather than saving everything as one big file, you would probably consider building a file system like Ivy which borrowed many ideas from LFS. you wrote: > > > >Does computational overhead in case of large, frequently changing files, > > >speak against content-hashing ? > > > > Perhaps. Can you suggest any large files that are frequently changing > > and stored in a p2p system? > > > > I can think of large, frequently changing files that are not stored in > > a p2p system. And I can think of large, basically unchanging files > > that ARE stored in a p2p system. But I have a hard time thinking of > > examples that have all of those characteristics. > > > > > ::Sigh:: Confession: I was thinking quite mechanically, just looking for > what would be _bad_ for content-hashing, rather than practically. > > A node on a p2p net, that apart from allowing uploads from its local disk, > also does the server-like job of logging all incoming requests (say source > IPs or some such), for offline processing could lead to a large, changing-often > file stored on it. > > The typical kind of files stored today in p2p nets (mp3, video) are > ofcourse large and unchanging, but what would prevent large, > changing-often files from being stored in a p2p net ? > > -Shshank Sharma From shshanks@nunki.usc.edu Thu May 15 10:38:25 2003 From: shshanks@nunki.usc.edu (Shshank Sharma) Date: Thu, 15 May 2003 02:38:25 -0700 (PDT) Subject: [Csci551-talk] content-hashing in p2p nets In-Reply-To: <200305150203.h4F23qSD017279@enl.usc.edu> Message-ID: Yes, _good_ design would make good things happen, I am sure. Could you offer some pointers towards Ivy, LFS et al ? I'm new to it. An aside, aren't bad design choices a bigger bane for p2p, as compared to conventional centralized architectures, because we are "shifting control to the periphery" ? Perhaps. http://www.spectrum.ieee.org/spectrum/may03/departments/refl.html offers some comments, not necessarily about the "banes" though. I'm not sure I know of any serious uses of p2p (as yet) apart from sharing mp3 files,video etc., things that the entertainment industry seeks to put an end to, and soon. What could perhaps be better uses ? And while we are at it, why do p2p softwares like KaZaa, Bearshare make the machine go slow ? Lots of questions, and the semester is already over ! Thanks, it has been a good semester, and best of luck, everybody. -Sharma On Wed, 14 May 2003, Omprakash Gnawali wrote: > > For that application, rather than saving everything as one big file, > you would probably consider building a file system like Ivy which > borrowed many ideas from LFS. > > you wrote: > > > > > >Does computational overhead in case of large, frequently changing files, > > > >speak against content-hashing ? > > > > > > Perhaps. Can you suggest any large files that are frequently changing > > > and stored in a p2p system? > > > > > > I can think of large, frequently changing files that are not stored in > > > a p2p system. And I can think of large, basically unchanging files > > > that ARE stored in a p2p system. But I have a hard time thinking of > > > examples that have all of those characteristics. > > > > > > > > > ::Sigh:: Confession: I was thinking quite mechanically, just looking for > > what would be _bad_ for content-hashing, rather than practically. > > > > A node on a p2p net, that apart from allowing uploads from its local disk, > > also does the server-like job of logging all incoming requests (say source > > IPs or some such), for offline processing could lead to a large, changing-often > > file stored on it. > > > > The typical kind of files stored today in p2p nets (mp3, video) are > > ofcourse large and unchanging, but what would prevent large, > > changing-often files from being stored in a p2p net ? > > > > -Shshank Sharma > From gnawali@usc.edu Thu May 15 19:10:30 2003 From: gnawali@usc.edu (Omprakash Gnawali) Date: Thu, 15 May 2003 11:10:30 -0700 Subject: [Csci551-talk] content-hashing in p2p nets In-Reply-To: Your message of Thu, 15 May 2003 02:38:25 -0700 (PDT) Message-ID: <200305151810.h4FIAUUu026193@enl.usc.edu> LFS: http://citeseer.nj.nec.com/rosenblum90lfs.html Ivy: http://citeseer.nj.nec.com/muthitacharoen02ivy.html you wrote: > > Yes, _good_ design would make good things happen, I am sure. > Could you offer some pointers towards Ivy, LFS et al ? > I'm new to it. > > An aside, aren't bad design choices a bigger bane for p2p, as compared to > conventional centralized architectures, because we are "shifting control > to the periphery" ? Perhaps. > http://www.spectrum.ieee.org/spectrum/may03/departments/refl.html offers > some comments, not necessarily about the "banes" though. > > I'm not sure I know of any serious uses of p2p (as yet) apart from sharing > mp3 files,video etc., things that the entertainment industry seeks to put a *n > end to, and soon. What could perhaps be better uses ? > And while we are at it, why do p2p softwares like KaZaa, Bearshare make > the machine go slow ? > > Lots of questions, and the semester is already over ! > Thanks, it has been a good semester, and best of luck, everybody. > > -Sharma > > On Wed, 14 May 2003, Omprakash Gnawali wrote: > > > > For that application, rather than saving everything as one big file, > > you would probably consider building a file system like Ivy which > > borrowed many ideas from LFS. > > > > you wrote: > > > > > > > >Does computational overhead in case of large, frequently changing fi *les, > > > > >speak against content-hashing ? > > > > > > > > Perhaps. Can you suggest any large files that are frequently changin *g > > > > and stored in a p2p system? > > > > > > > > I can think of large, frequently changing files that are not stored i *n > > > > a p2p system. And I can think of large, basically unchanging files > > > > that ARE stored in a p2p system. But I have a hard time thinking of > > > > examples that have all of those characteristics. > > > > > > > > > > > > > ::Sigh:: Confession: I was thinking quite mechanically, just looking fo *r > > > what would be _bad_ for content-hashing, rather than practically. > > > > > > A node on a p2p net, that apart from allowing uploads from its local di *sk, > > > also does the server-like job of logging all incoming requests (say sou *rce > > > IPs or some such), for offline processing could lead to a large, changi *ng-often > > > file stored on it. > > > > > > The typical kind of files stored today in p2p nets (mp3, video) are > > > ofcourse large and unchanging, but what would prevent large, > > > changing-often files from being stored in a p2p net ? > > > > > > -Shshank Sharma > > > > From sarangar@usc.edu Thu May 15 20:59:15 2003 From: sarangar@usc.edu (Ramesh Sarangarajan) Date: Thu, 15 May 2003 12:59:15 -0700 Subject: [Csci551-talk] NetGames 2003 Workshop Message-ID: <000e01c31b1c$76fa3850$3201a8c0@Intrepid> There is a workshop on "networking support for multiplayer games" to be held on May 22-23, 2003 at Electronic Arts Headquarters, Redwood City, CA. Interested folks could look at http://confman.eecs.umich.edu/netgames2003/Program.html -Ramesh