From phamductri at berkeley.edu Fri Nov 2 18:22:54 2007 From: phamductri at berkeley.edu (phamductri at berkeley.edu) Date: Fri, 2 Nov 2007 18:22:54 -0700 (PDT) Subject: [ee122] Looking for a partner in proj2 Message-ID: <48557.128.32.253.149.1194052974.squirrel@calmail.berkeley.edu> Hi there, I still don't have a partner for project 2. So please reply if you're in need of a partner. Thanks Tri From vern at cs.berkeley.edu Sat Nov 3 12:29:17 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Sat, 03 Nov 2007 12:29:17 -0700 Subject: [ee122] pseudo-code for TCP congestion control Message-ID: <200711031929.lA3JTKY0028351@pork.ICSI.Berkeley.EDU> A number of students asked for pseudo-code for how a TCP sender executes the congestion control and retransmission algorithms, so I've put together the appended. If you have questions about it, I encourage you to send them to the mailing list, as likely others will be wondering the same things. (Also, it's possible there are some bugs in this, as it's something I've newly written - if you spot something that doesn't look right, please feel free to point that out as well.) Vern Initialization: # Congestion window. Actual window used by sender is minimum of # this and the "offered window" specified by the receiver in each # acknowledgment (or data packet, for that matter) they send to us. CWND <- MSS # Slow-Start threshold. If CWND is less than or equal to this value, # then we operate in Slow Start. If CWND is larger than this value, # then we operate in Congestion Avoidance, i.e., linear increase. SSTHRESH <- Infinity # The following variable holds the value of the highest sequence # number we've sent. MaxSent <- 0 # The following variable holds the highest sequence number that the # receiver has acknowledged. MaxAcked <- 0 # Count of how many duplicate acks ("dups") we've received. NuMDups <- 0 # Now that we've initialized, we send as much data as allowed, # which will be limited by CWND to a single full-sized (MSS) packet. SendPackets(1, CWND) Upon receiving an ACK for sequence AckSeq: if AckSeq == MaxAcked && offered window hasn't changed then ++NumDups if NumDups == 3 then FastRetransmit() return # Not a duplicate ack. NumDups <- 0 update offered window if AckSeq > MaxAcked then # This acknowledges new data. MaxAcked <- AckSeq free up memory buffering data up to MaxAcked # Update the operation of the retransmission timer. if this ack gives us a new RTT measurement update our RTT estimators recompute RTO based on new estimates restart retransmission timeout # Update congestion control window. if CWND <= SSTHRESH then # We are in Slow Start. Note, some TCPs use # a test of CWND < SSTHRESH instead of <=. CWND += MSS # increase by one packet per ack else # We are in Congestion Avoidance - linear increase. # Here we use the form that makes a small update # for each incoming ack, and is not quite linear. CWND += MSS * MSS / CWND # Send any new data allowed by changes from this ack to either # the offered window, CWND, or MaxAcked. Window <- Min(offered window, CWND) if MaxAcked + Window > MaxSent then # Send all data between MaxAcked+Window and what we've # sent so far. SendPackets(MaxSent, MaxAcked + Window - MaxSent) Upon a retransmission timeout: SSTHRESH <- CWND / 2 # multiplicative decrease # Begin Slow Start. CWND <- MSS # Exponentially back off retransmission timer. RTO <- RTO * 2 # Make no assumptions about the past. In particular, # do *not* presume that any packets sent past this one # have made it to the receiver. If we left MaxSent alone, # then upon receiving an acknowledgment for the packet # we're about to send, we often wouldn't be able to send any # additional data since CWND wouldn't extend us past the # old value of MaxSent. MaxSent <- MaxAcked NumDups <- 0 # Retransmit a single packet, namely the first one for which # we haven't received an ack. SendPackets(MaxAcked, MSS) function SendPackets(StartingSeqNum, Size) # Note, in this example we always send full-sized packets. FinalSeq <- StartingSeqNum + Size - 1 while StartingSeqNum < FinalSeq do transmit an MSS-sized packet with sequence number StartingSeqNum StartingSeqNum += MSS if FinalSeq > MaxSent then MaxSent <- FinalSeq function FastRetransmit() # Multiplicative decrease. SSTHRESH <- CWND / 2 # We do not cut CWND all the way down to the beginning of # a Slow Start. Instead, we just halve it and will proceed # in Congestion Avoidance. CWND <- SSTHRESH # Note that unlike how we handled a retransmission timeout, # here we do *not* alter MaxSent. This means that if we # receive an ack for just the packet we're retransmitting, # instead of an ack further along that includes some of the # packets we sent earlier, then we might not be able to send # anything new in response to that ack. Basically, we're # betting here that only a single packet has been lost, and # once we retransmit it the receiver will send us an ack # all the way up to MaxSent. If that's not the case, then # we will stall until RTO goes off for a timeout retranmissions. # Retransmit a single packet - the one called for by the dups. SendPackets(MaxAcked, MSS) From apolloellis at berkeley.edu Sat Nov 3 12:49:12 2007 From: apolloellis at berkeley.edu (apolloellis at berkeley.edu) Date: Sat, 3 Nov 2007 12:49:12 -0700 (PDT) Subject: [ee122] partner for proj2 Message-ID: <2060.69.107.119.49.1194119352.squirrel@calmail.berkeley.edu> Hi, I am looking for a project 2 partner who at least finished both projects and knows c++. If you're interested please email me asap at: apolloellis at berkeley.edu Apollo From huntingtonsurfca at gmail.com Sat Nov 3 15:51:21 2007 From: huntingtonsurfca at gmail.com (Richard Schmidt) Date: Sat, 3 Nov 2007 15:51:21 -0700 Subject: [ee122] Looking for partner, please read. Message-ID: I have finished both projects before the due date, with little or no bug problems in either project. Looking for a partner that wants to work on the project in chunks (one day a week), instead of all at the end (although I'm sure the weekend before will be all bug fixing). If you can work one full day each weekend, let me know. I do things hardcore in ANSI C (to the max!), and have done C++ before but not intimately. Facebook me if you want more info about me. Richard Schmidt From huntingtonsurfca at gmail.com Sat Nov 3 18:03:10 2007 From: huntingtonsurfca at gmail.com (Richard Schmidt) Date: Sat, 3 Nov 2007 18:03:10 -0700 Subject: [ee122] Format of DV table entry Message-ID: There's no example of what the book thinks are Distance Vector table entries. They have tables that change over time, but the lecture notes have a different table. Which table am I supposed to use and am I supposed to show time progression or just the end product? Rick From huntingtonsurfca at gmail.com Sat Nov 3 20:43:49 2007 From: huntingtonsurfca at gmail.com (Richard Schmidt) Date: Sat, 3 Nov 2007 20:43:49 -0700 Subject: [ee122] HW Problem 2-> (4.29) Message-ID: I don't quite understand this question, with respect to the fact that it says "Suppose eBGP and iBGP are used for inter-AS routing." iBGP is for intra-AS routing sessions... so why would it be used for talking to another AS? Furthermore, let's say some AS was running OSPF (as in the problem) and the border router was using eBGP to speak to other AS border routers. Would the border router speak to its network in iBGP, only its neighbor router in iBGP or none (since the AS is defined as OSPF) at all? I'm confused because when the book talks about routing protocols, all the routers in the example use the same protocol, with no mixing... Any hints or clarifications would be helpful. I've skimmed/read the routing protocols from the book a couple times and also read the slodes on BGP, but nothing really talks about gateway/intra-AS talking. Thanks, Rick From vern at cs.berkeley.edu Sat Nov 3 21:07:49 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Sat, 03 Nov 2007 21:07:49 -0700 Subject: [ee122] HW Problem 2-> (4.29) In-Reply-To: (Sat, 03 Nov 2007 20:43:49 PDT). Message-ID: <200711040407.lA447q2X002850@pork.ICSI.Berkeley.EDU> > I don't quite understand this question, with respect to the fact that > it says "Suppose eBGP and iBGP are used for inter-AS routing." iBGP is > for intra-AS routing sessions... iBGP is used to distribute inter-AS routing information inside a single AS (between the routers in the AS that need to know about the inter-AS routing information). It is *not* used for intra-AS routing itself. Vern From ericcheung at berkeley.edu Sun Nov 4 17:22:49 2007 From: ericcheung at berkeley.edu (Eric Cheung) Date: Sun, 04 Nov 2007 17:22:49 -0800 Subject: [ee122] hw3, #5 close connection? Message-ID: <472E7069.8020804@berkeley.edu> For question 5, are we supposed to assume the connection is closed after we are finished downloading the webpage? Thanks - Eric From fowler at eecs.berkeley.edu Sun Nov 4 18:04:37 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Sun, 4 Nov 2007 18:04:37 -0800 Subject: [ee122] Project 2 concerns - READ ME! Message-ID: <330471bf0711041804k6711c009y455ad1f339793f1d@mail.gmail.com> Hi all- I've heard from many students that there is concern about the influence and presence of Project 1 code in Project 2. I have clarified in 1-on-1 conversations and in my section, but that clearly doesn't reach all of you. I hope this email will help to reduce some of your concerns. The MAIN FOCUS of Project 2 is the custom protocol that you create from scratch. The use of Project 1 client/server in Project 2 is only so that you have something that will be able to TEST your custom protocol. I will NOT be grading your Project 1 client/server in the same manner that it was graded for Project 1. Don't think of Project 2 as an extension of Project 1. All that your Project 1 client and server have to do in Project 2 is *transfer a single file to a single client*. I don't care about error codes, simultaneous clients, spurious tokens, chunking, nothing. All I need is that your PREFERRED (!) Project 1 solution is able to request a single file, transfer data across a network, and save that file. Everything else in the Project 1 grading rubric is not critical if you can request/transfer/save that file. I know some of you are bummed that we aren't doing a p2p program, but trust me -- you are going to be really glad that you didn't have to design and build a p2p program IN ADDITION to designing and building your custom protocol. :) Please read the Project 2 spec in its entirety and let me know if you still have additional concerns about this. The main focus of Project 2 is the custom protocol. Don't get stressed about having the most perfect Project 1 solution before you even begin to work on Project 2. Take a break from thinking about Project 1 and instead spend your energy on coming up with a fabulous proposal for a brilliant new reliable transport protocol :) -Lisa From vern at cs.berkeley.edu Mon Nov 5 00:37:59 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Mon, 05 Nov 2007 00:37:59 -0800 Subject: [ee122] Format of DV table entry In-Reply-To: (Sat, 03 Nov 2007 18:03:10 PDT). Message-ID: <200711050838.lA58c26h017637@pork.ICSI.Berkeley.EDU> > There's no example of what the book thinks are Distance Vector table entries. See figure 4.30. > They have tables that change over time, but the lecture notes have a > different table. As explained in the lecture slides, the tables I used were simplified to only show best paths. > Which table am I supposed to use The style in the text. > and am I supposed to show time > progression or just the end product? Problem 2(c) explicitly states to show the tables at each iteration. Vern From jortiz at cs.berkeley.edu Mon Nov 5 07:48:40 2007 From: jortiz at cs.berkeley.edu (Jorge Ortiz) Date: Mon, 5 Nov 2007 07:48:40 -0800 Subject: [ee122] hw3, #5 close connection? In-Reply-To: <472E7069.8020804@berkeley.edu> References: <472E7069.8020804@berkeley.edu> Message-ID: Yes, assume that it's an HTTP 1.0 fetch and thus closed after the page is returned. jorge On 11/4/07, Eric Cheung wrote: > For question 5, are we supposed to assume the connection is closed after > we are finished downloading the webpage? > > Thanks > - Eric > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From huntingtonsurfca at gmail.com Mon Nov 5 13:09:28 2007 From: huntingtonsurfca at gmail.com (Richard Schmidt) Date: Mon, 5 Nov 2007 13:09:28 -0800 Subject: [ee122] Delayed ACK and CWND movement Message-ID: Doing the homework, TCP sends data ACK's every other packet it recieves. When I was thinking about the CWND, I got confused as to how much this would increase if the ACK's came only after every other packet (i.e. half as many ACK's). I would think that the CWND would grow half as fast as a result (since upon an ACK, CWND += MSS*(MSS/CWND)). But when I was thinking about it rationally, the point of the previous equation was to increment packets sent by 1MSS every RTT, and if this was followed, then the ACK coming after about 2RTT's would let the CWND increase at the same rate as if the ACK's came after every packet. Can you please help clarify the equational relation and the rationale? Thanks, Rick From vern at cs.berkeley.edu Mon Nov 5 14:06:20 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Mon, 05 Nov 2007 14:06:20 -0800 Subject: [ee122] Delayed ACK and CWND movement In-Reply-To: (Mon, 05 Nov 2007 13:09:28 PST). Message-ID: <200711052206.lA5M6MTS000698@pork.ICSI.Berkeley.EDU> > Doing the homework, TCP sends data ACK's every other packet it recieves. Right, though we haven't covered this yet. (We will in Wednesday's lecture.) > When I was thinking about the CWND, I got confused as to how much this > would increase if the ACK's came only after every other packet (i.e. > half as many ACK's). I would think that the CWND would grow half as > fast as a result (since upon an ACK, CWND += MSS*(MSS/CWND)). Indeed it does, if one uses that formulation for congestion avoidance. Remember that another formulation is to track a packet per flight, and bump by MSS when it's ack'd - that approach doesn't have this problem. Vern From a_kilman at berkeley.edu Mon Nov 5 19:55:16 2007 From: a_kilman at berkeley.edu (Anthony Kilman) Date: Mon, 05 Nov 2007 19:55:16 -0800 Subject: [ee122] HW 3, Problem 4 Message-ID: <1194321316.23236.2.camel@zerocool> In problem 4 there is no mention of aging time (time to throw out a MAC entry). Are we assuming that there is none, and that the only form of purging an entry is pushing it out through future entries? Just want to be sure. Thanks in advance. Anthony From vern at cs.berkeley.edu Mon Nov 5 19:56:35 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Mon, 05 Nov 2007 19:56:35 -0800 Subject: [ee122] HW 3, Problem 4 In-Reply-To: <1194321316.23236.2.camel@zerocool> (Mon, 05 Nov 2007 19:55:16 PST). Message-ID: <200711060356.lA63ubtX005693@pork.ICSI.Berkeley.EDU> > In problem 4 there is no mention of aging time (time to throw out a MAC > entry). Are we assuming that there is none, and that the only form of > purging an entry is pushing it out through future entries? Yes, correct. Vern From vern at cs.berkeley.edu Mon Nov 5 23:33:06 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Mon, 05 Nov 2007 23:33:06 -0800 Subject: [ee122] pseudo-code for TCP congestion control In-Reply-To: (Sat, 03 Nov 2007 12:29:17 PDT). Message-ID: <200711060733.lA67X861008427@pork.ICSI.Berkeley.EDU> There's a bug in the pseudo-code here: > function FastRetransmit() > # Multiplicative decrease. > SSTHRESH <- CWND / 2 > > # We do not cut CWND all the way down to the beginning of > # a Slow Start. Instead, we just halve it and will proceed > # in Congestion Avoidance. > CWND <- SSTHRESH The comment about CWND is (essentially) correct for a refinement to Fast Retransmission that we will meet in lecture this Wednesday, termed "Fast Recovery". However, for Fast Retransmission the correct code is CWND <- MSS. This next part remains, though: > # Note that unlike how we handled a retransmission timeout, > # here we do *not* alter MaxSent. This means that if we > # receive an ack for just the packet we're retransmitting, > # instead of an ack further along that includes some of the > # packets we sent earlier, then we might not be able to send > # anything new in response to that ack. Basically, we're > # betting here that only a single packet has been lost, and > # once we retransmit it the receiver will send us an ack > # all the way up to MaxSent. If that's not the case, then > # we will stall until RTO goes off for a timeout retranmissions. So after the single packet is retransmitted, CWND is too small to send anything further upon any future acks unless they happen to be for all the way up MaxSent. I'll send corrected pseudo code in the next message. Vern From vern at icir.org Mon Nov 5 23:37:07 2007 From: vern at icir.org (Vern Paxson) Date: Mon, 05 Nov 2007 23:37:07 -0800 Subject: [ee122] corrected pseudo-code for TCP congestion control (fix for FastRetransmit) In-Reply-To: (Sat, 03 Nov 2007 12:29:17 PDT). Message-ID: <200711060737.lA67b9dB008499@pork.ICSI.Berkeley.EDU> Initialization: # Congestion window. Actual window used by sender is minimum of # this and the "offered window" specified by the receiver in each # acknowledgment (or data packet, for that matter) they send to us. CWND <- MSS # Slow-Start threshold. If CWND is less than or equal to this value, # then we operate in Slow Start. If CWND is larger than this value, # then we operate in Congestion Avoidance, i.e., linear increase. SSTHRESH <- Infinity # The following variable holds the value of the highest sequence # number we've sent. MaxSent <- 0 # The following variable holds the highest sequence number that the # receiver has acknowledged. MaxAcked <- 0 # Count of how many duplicate acks ("dups") we've received. NuMDups <- 0 # Now that we've initialized, we send as much data as allowed, # which will be limited by CWND to a single full-sized (MSS) packet. SendPackets(1, CWND) Upon receiving an ACK for sequence AckSeq: if AckSeq == MaxAcked && offered window hasn't changed then ++NumDups if NumDups == 3 then FastRetransmit() return # Not a duplicate ack. NumDups <- 0 update offered window if AckSeq > MaxAcked then # This acknowledges new data. MaxAcked <- AckSeq free up memory buffering data up to MaxAcked # Update the operation of the retransmission timer. if this ack gives us a new RTT measurement update our RTT estimators recompute RTO based on new estimates restart retransmission timeout # Update congestion control window. if CWND <= SSTHRESH then # We are in Slow Start. Note, some TCPs use # a test of CWND < SSTHRESH instead of <=. CWND += MSS # increase by one packet per ack else # We are in Congestion Avoidance - linear increase. # Here we use the form that makes a small update # for each incoming ack, and is not quite linear. CWND += MSS * MSS / CWND # Send any new data allowed by changes from this ack to either # the offered window, CWND, or MaxAcked. Window <- Min(offered window, CWND) if MaxAcked + Window > MaxSent then # Send all data between MaxAcked+Window and what we've # sent so far. SendPackets(MaxSent, MaxAcked + Window - MaxSent) Upon a retransmission timeout: SSTHRESH <- CWND / 2 # multiplicative decrease # Begin Slow Start. CWND <- MSS # Exponentially back off retransmission timer. RTO <- RTO * 2 # Make no assumptions about the past. In particular, # do *not* presume that any packets sent past this one # have made it to the receiver. If we left MaxSent alone, # then upon receiving an acknowledgment for the packet # we're about to send, we often wouldn't be able to send any # additional data since CWND wouldn't extend us past the # old value of MaxSent. MaxSent <- MaxAcked NumDups <- 0 # Retransmit a single packet, namely the first one for which # we haven't received an ack. SendPackets(MaxAcked, MSS) function SendPackets(StartingSeqNum, Size) # Note, in this example we always send full-sized packets. FinalSeq <- StartingSeqNum + Size - 1 while StartingSeqNum < FinalSeq do transmit an MSS-sized packet with sequence number StartingSeqNum StartingSeqNum += MSS if FinalSeq > MaxSent then MaxSent <- FinalSeq function FastRetransmit() # Multiplicative decrease. SSTHRESH <- CWND / 2 # Cut CWND all the way down to begin Slow Start. However, # we won't actually slow-start unless only a single packet # (or in some cases a few) was lost and the next ack we # receive is for all of the outstanding data. # # FYI, a refinement to FastRetransmit, termed "Fast Recovery", # doesn't cut CWND in this fashion. By keeping CWND larger # (which it does in a somewhat peculiar fashion), it lets # us continue to transmit data when more duplicate ACKs arrive, # and to wind up right at the correct rate (i.e., SSTHRESH) # when all the lost data has been retransmitted. CWND <- MSS # Note that unlike how we handled a retransmission timeout, # here we do *not* alter MaxSent. This means that if we # receive an ack for just the packet we're retransmitting, # instead of an ack further along that includes some of the # packets we sent earlier, then we might not be able to send # anything new in response to that ack. Basically, we're # betting here that only a single packet has been lost, and # once we retransmit it the receiver will send us an ack # all the way up to MaxSent. If that's not the case, then # we will stall until RTO goes off for a timeout retranmissions. # Retransmit a single packet - the one called for by the dups. SendPackets(MaxAcked, MSS) From jessealbini at berkeley.edu Tue Nov 6 15:06:31 2007 From: jessealbini at berkeley.edu (Jesse Albini) Date: Tue, 06 Nov 2007 15:06:31 -0800 Subject: [ee122] Looking for a Project 2 Partner Message-ID: <4730F377.1010205@berkeley.edu> I'm looking for a partner to work on project 2 with. I'm a senior CS major who would prefer to code in C++ (although C would be fine too). I'm pretty easy going, but I don't want to waste time, as there are a lot of things coming up in my other classes. I also love debugging, as masochistic as that sounds, so if you hate it, perhaps we'd be a good match ^^b. If you're interested, send me an e-mail at jessealbini at berkeley.edu. Jesse From jawwadmemon at berkeley.edu Tue Nov 6 19:11:30 2007 From: jawwadmemon at berkeley.edu (Jawwad) Date: Tue, 6 Nov 2007 19:11:30 -0800 Subject: [ee122] Looking for partner for proj2 Message-ID: Hi, I am looking for a proj2 partner. If you are interested please reply asap so we can get started on it. I am a last semester CS major, prefer to code in C. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071106/e493b4b6/attachment.html From jde at berkeley.edu Tue Nov 6 21:59:52 2007 From: jde at berkeley.edu (Jonathan D. Ellithorpe) Date: Tue, 06 Nov 2007 21:59:52 -0800 Subject: [ee122] [Project2] Congestion "Fairness" Message-ID: <47315458.1090603@berkeley.edu> I was just wondering what is meant by "Fairness" with respect to congestion control algorithms. I can see that simply having congestion control is more "fair" in relation to the use of the network by many users, but I don't really know how to compare the fairness of two different congestion control algorithms. Any guidance would be greatly appreciated. Jonathan From jortiz at cs.berkeley.edu Tue Nov 6 22:19:27 2007 From: jortiz at cs.berkeley.edu (Jorge Ortiz) Date: Tue, 6 Nov 2007 22:19:27 -0800 Subject: [ee122] [Project2] Congestion "Fairness" In-Reply-To: <47315458.1090603@berkeley.edu> References: <47315458.1090603@berkeley.edu> Message-ID: Fairness is essentially related to every participant getting their fair share of the network resources (bandwidth). If two sources are continuously sending data they should each get half the bandwidth. Fairness measure can actually be a bit more complicated if you consider each source's send rate. The intuition is that if a sender does not have as much to send, it doesn't necessarily need half the bandwidth. Queue-management mechanisms can assure fairness for a set of senders by trying to determine the send rate for each sender and alotting enough bandwidth (queue space) for each source to obtain their maximum send rate. Jorge On 11/6/07, Jonathan D. Ellithorpe wrote: > I was just wondering what is meant by "Fairness" with respect to > congestion control algorithms. I can see that simply having congestion > control is more "fair" in relation to the use of the network by many > users, but I don't really know how to compare the fairness of two > different congestion control algorithms. Any guidance would be greatly > appreciated. > > Jonathan > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From jortiz at cs.berkeley.edu Tue Nov 6 22:21:05 2007 From: jortiz at cs.berkeley.edu (Jorge Ortiz) Date: Tue, 6 Nov 2007 22:21:05 -0800 Subject: [ee122] [Project2] Congestion "Fairness" In-Reply-To: References: <47315458.1090603@berkeley.edu> Message-ID: There's a common fairness metric used called Jain's fairness metric (http://en.wikipedia.org/wiki/Fairness_measure). This is used to compare fairness among senders. Jorge On 11/6/07, Jorge Ortiz wrote: > Fairness is essentially related to every participant getting their > fair share of the network resources (bandwidth). If two sources are > continuously sending data they should each get half the bandwidth. > > Fairness measure can actually be a bit more complicated if you > consider each source's send rate. The intuition is that if a sender > does not have as much to send, it doesn't necessarily need half the > bandwidth. Queue-management mechanisms can assure fairness for a set > of senders by trying to determine the send rate for each sender and > alotting enough bandwidth (queue space) for each source to obtain > their maximum send rate. > > Jorge > > > On 11/6/07, Jonathan D. Ellithorpe wrote: > > I was just wondering what is meant by "Fairness" with respect to > > congestion control algorithms. I can see that simply having congestion > > control is more "fair" in relation to the use of the network by many > > users, but I don't really know how to compare the fairness of two > > different congestion control algorithms. Any guidance would be greatly > > appreciated. > > > > Jonathan > > _______________________________________________ > > ee122 mailing list > > ee122 at mailman.ICSI.Berkeley.EDU > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > > From vern at cs.berkeley.edu Wed Nov 7 00:11:34 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Wed, 07 Nov 2007 00:11:34 -0800 Subject: [ee122] [Project2] Congestion "Fairness" In-Reply-To: <47315458.1090603@berkeley.edu> (Tue, 06 Nov 2007 21:59:52 PST). Message-ID: <200711070811.lA78Bd9M005543@pork.ICSI.Berkeley.EDU> Just to add to what Jorge said: don't worry about any deep sort of analysis here, the point for Phase 1 is simply for you to think about how does your proposed scheme divide up capacity among multiple senders. (In particular, don't worry about Jain's fairness metric or such.) Vern From adeguzman at berkeley.edu Wed Nov 7 01:13:50 2007 From: adeguzman at berkeley.edu (Alan Deguzman) Date: Wed, 7 Nov 2007 01:13:50 -0800 Subject: [ee122] project 2 partner Message-ID: Does anyone still need a project partner? If so, please let me know ASAP! I prefer to code in c, but c++ is fine also. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071107/036afea6/attachment.html From chenchang at berkeley.edu Wed Nov 7 08:07:16 2007 From: chenchang at berkeley.edu (Chen Chang) Date: Wed, 7 Nov 2007 08:07:16 -0800 (PST) Subject: [ee122] proj2 partner Message-ID: <1735.69.110.10.182.1194451636.squirrel@calmail.berkeley.edu> Hi all, I'm looking for a partner for project 2. If anybody out there is in the same boat, please send me a message at chenchang at berkeley.edu. Thanks! Chen From fowler at eecs.berkeley.edu Wed Nov 7 19:01:09 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Wed, 7 Nov 2007 19:01:09 -0800 Subject: [ee122] Note about Project 2 - Phase 1 submission rules Message-ID: <330471bf0711071901h382ff5d4u8e03471daa4d594c@mail.gmail.com> Hi all- ------------------------------------------ Short version of this email: * Stapled legible paper submissions in Cory drop box by 11pm Nov 13 OR * Email a single PDF/DOC/TXT/RTF file to fowler at eecs.berkeley.edu by 11pm Nov 13 For both: * Both of your email addresses on the first page * EVERY PAGE MUST HAVE: both names, both inst IDs, page # * Verify that your doc is in compliance with the above, legible, printable, and not missing elements * I will ACK receipt by 12pm Nov 14. Verify above and resubmit if you don't hear from me. * If you fail to do all of the above by 11pm Nov 13, it will make your phase 1 "late" ------------------------------------------ For your Proj 2 Phase 1 design doc, YOU **MUST** HAVE ON EVERY PAGE: - BOTH of your NAMES and corresponding INST IDs - page number out of total pages You must verify on your own that printing and presentation is not buggy. I will not debug your documents for legibility or for missing/misaligned elements. This is all for your own benefit! Make sure I can give you the best grade I can for your *content* by making sure the presentation isn't a hindrance. (Hint: A happy TA is a better grader :) ) Submissions for Project 2 Phase 1 can be electronic or paper-based in the drop-box. If you choose to submit a legible stapled paper-based document via the Cory drop-box, you must make sure that you can gain access to Cory BEFORE the deadline. If you submit your design document to me electronically, send only a *single* PDF/DOC/TXT/RTF file via email to fowler at eecs.berkeley.edu . Make sure you put both of your email addresses on the first page of the doc so that I know who to email. Via email, to the email addresses you specify, I will ACK my receipt of your design doc and ability to read/print it by 12pm Wednesday Nov 14. If you do not hear from me, you may assume that either you did not follow ALL of the above or that I didn't receive the doc. It is your responsibility to ensure reliable and timely delivery. If you don't hear from me, it means you are subject to the late penalty and you should make sure to submit a better copy before the 24hr deadline. You are all very smart (to my knowledge ;) ). Make sure that you enable me to reward you for being smart by doing *all* of the above. Thanks for helping me help you get the grade you deserve on this phase. -Lisa From davide.cerri at gmail.com Fri Nov 9 18:53:41 2007 From: davide.cerri at gmail.com (Davide Cerri) Date: Fri, 9 Nov 2007 18:53:41 -0800 Subject: [ee122] my_connect , my_listen ..... etc Message-ID: hello, i am writing to understand why would we have to implement this functions? I thought that once i set my socket with SOCK_DGRAM i could use send , listen and receive, normally with the only difference that packages would be shipped with UDP. Are those functions only a wrapper to the real functions, with the only difference that they would read and handle our header? thanks -- ~/Davide Cerri From fowler at eecs.berkeley.edu Fri Nov 9 19:26:54 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Fri, 9 Nov 2007 19:26:54 -0800 Subject: [ee122] my_connect , my_listen ..... etc In-Reply-To: References: Message-ID: <330471bf0711091926w5be521vbb6e0f8529af14ec@mail.gmail.com> Good question. You use the SOCK_DGRAM to create the unreliable underlying transport protocol. Above that is MNL, e.g. you would use the MNL_sendto() instead of the UDP sendto() --- MNL_sendto() is a wrapper to the UDP sendto(). But while there's all of that, the task here is to create a library that you will use instead of directly interacting with these UDP or even MNL listen(), etc. notions. So yes, you are making system call wrappers. Your custom library methods (wrappers of the UDP or MNL functions) will provide the extra features that UDP does *not* provide. You should ideally make MINIMAL changes to your HTTP client/server by only changing the TCP calls with calls into your library. I hope that helps.... Lisa On Nov 9, 2007 6:53 PM, Davide Cerri wrote: > hello, > i am writing to understand why would we have to implement this functions? > I thought that once i set my socket with SOCK_DGRAM i could use send , > listen and receive, normally with the only difference that packages > would be shipped with UDP. > Are those functions only a wrapper to the real functions, with the > only difference that they would read and handle our header? > > thanks > > -- > ~/Davide Cerri > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From davide.cerri at gmail.com Fri Nov 9 19:42:51 2007 From: davide.cerri at gmail.com (Davide Cerri) Date: Fri, 9 Nov 2007 19:42:51 -0800 Subject: [ee122] checksum Message-ID: Hello, do we need to implement some form of checksum to verify the integrity of our headers? I guess the client could mess up if for some reason our sequence numbers would get corrupted. -- ~/Davide Cerri From fowler at eecs.berkeley.edu Fri Nov 9 20:00:40 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Fri, 9 Nov 2007 20:00:40 -0800 Subject: [ee122] checksum In-Reply-To: References: Message-ID: <330471bf0711092000u4b41446av2f916368372e32c3@mail.gmail.com> That's your choice... Any "need to" questions here are going to be entirely subjective. You get to argue whether you do or you don't "need" such a thing. Remember, there isn't a "right" answer here that you're trying to achieve. You just want something that *works* according to the needs, and if it doesn't work with some things or under certain circumstances, you should acknowledge that it doesn't do that stuff and why you chose not to address those problems. -Lisa On Nov 9, 2007 7:42 PM, Davide Cerri wrote: > Hello, > do we need to implement some form of checksum to verify the integrity > of our headers? > I guess the client could mess up if for some reason our sequence > numbers would get corrupted. > > > -- > ~/Davide Cerri > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From nescionomen at gmail.com Sun Nov 11 16:39:10 2007 From: nescionomen at gmail.com (Nescio Nomen) Date: Sun, 11 Nov 2007 16:39:10 -0800 Subject: [ee122] FSM Message-ID: For the FSM we're turning in, does it have to include the send/receive parts of our protocol, or is it fine to just diagram only the connection establishment and termination, like what we saw in the discussion slides? Also, do we have to handle sudden terminations, eg RST flag? From vern at cs.berkeley.edu Sun Nov 11 17:12:34 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Sun, 11 Nov 2007 17:12:34 -0800 Subject: [ee122] FSM In-Reply-To: (Sun, 11 Nov 2007 16:39:10 PST). Message-ID: <200711120112.lAC1CdPP029639@pork.ICSI.Berkeley.EDU> > For the FSM we're turning in, does it have to include the send/receive > parts of our protocol, or is it fine to just diagram only the > connection establishment and termination, like what we saw in the > discussion slides? A good FSM diagram shows all the different states a connection can be in. For TCP, these are dominated by connection establishment & termination; for your protocol, that may well be the case too, but it's possible your protocol will have multiple states once a connection is estabished (say), depending on your design. Your FSM should show these. > Also, do we have to handle sudden terminations, eg > RST flag? It's okay to provide an annotation such as "in all states except XYZ, upon receiving a Termination packet the state transitions to state Done" or such. That is, it should be clear how receipt of something like a RST is dealt with in terms of state transitions, but doesn't need to be illustrated if it will clutter the diagram rather than help clarify how states change. Vern From ee122-dm at imail.EECS.Berkeley.EDU Sun Nov 11 18:26:04 2007 From: ee122-dm at imail.EECS.Berkeley.EDU (ee122-dm at imail.EECS.Berkeley.EDU) Date: Sun, 11 Nov 2007 18:26:04 -0800 (PST) Subject: [ee122] Project 2 partner Message-ID: <62631.67.169.102.122.1194834364.squirrel@imail.eecs.berkeley.edu> I know this is extremely late to be looking for a partner, but I am. I prefer to code in C, and if anyone still needs a partner, send an email to AirAndFingers at gmail.com .. I'll reply to this post if I find a partner. Thanks, Aaron From miken087 at berkeley.edu Sun Nov 11 18:47:02 2007 From: miken087 at berkeley.edu (Michael Ngo) Date: Sun, 11 Nov 2007 18:47:02 -0800 Subject: [ee122] ee122 project question Message-ID: <4737BEA6.3030603@berkeley.edu> How do you determine the MSS of the interface from which I am sending to? This is to set an initial value for the receiver's buffer size. Michael Ngo From nescionomen at gmail.com Sun Nov 11 19:09:19 2007 From: nescionomen at gmail.com (Nescio Nomen) Date: Sun, 11 Nov 2007 19:09:19 -0800 Subject: [ee122] FSM In-Reply-To: <200711120112.lAC1CdPP029639@pork.ICSI.Berkeley.EDU> References: <200711120112.lAC1CdPP029639@pork.ICSI.Berkeley.EDU> Message-ID: > > Also, do we have to handle sudden terminations, eg > > RST flag? > > It's okay to provide an annotation such as "in all states except XYZ, upon > receiving a Termination packet the state transitions to state Done" or > such. That is, it should be clear how receipt of something like a RST is > dealt with in terms of state transitions, but doesn't need to be illustrated > if it will clutter the diagram rather than help clarify how states change. > > Vern > Sorry, maybe I should've been more clear. TCP only sends a RST flagged packet when a program unexpectedly terminates, eg a crash. I am not sure how, in our own implementation of a reliable transport protocol (the actual code), we would send a packet after our program crashes. Since our program crashes, how would we get it to do anything? So I was wondering if it's a requirement to handle abrupt terminations. I'm guessing that you're implying it is? From fowler at eecs.berkeley.edu Sun Nov 11 19:11:13 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Sun, 11 Nov 2007 19:11:13 -0800 Subject: [ee122] ee122 project question In-Reply-To: <4737BEA6.3030603@berkeley.edu> References: <4737BEA6.3030603@berkeley.edu> Message-ID: <330471bf0711111911w3d83218bw285b2057cb1bd3d4@mail.gmail.com> Given that the MSS is an abstraction provided by TCP, this is something that you should decide and provide with your protocol. You may think of these things as "if TCP is the protocol that provides a particular feature and no other underlying protocol provides that feature, I should have to provide that feature in my replacement-for-TCP protocol." -Lisa On Nov 11, 2007 6:47 PM, Michael Ngo wrote: > How do you determine the MSS of the interface from which I am sending > to? This is to set an initial value for the receiver's buffer size. > > Michael Ngo > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From vern at cs.berkeley.edu Sun Nov 11 19:12:20 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Sun, 11 Nov 2007 19:12:20 -0800 Subject: [ee122] FSM In-Reply-To: (Sun, 11 Nov 2007 19:09:19 PST). Message-ID: <200711120312.lAC3CPIo030988@pork.ICSI.Berkeley.EDU> > ... I am not sure how, in our own implementation of a reliable transport > protocol (the actual code), we would send a packet after our program > crashes. You don't need to worry about this case, because for this project you indeed won't have any easy way to send such an emergency-teardown message. > So I was wondering if it's a requirement to handle abrupt > terminations. I'm guessing that you're implying it is? Per the above, no, not a requirement. Vern From fowler at eecs.berkeley.edu Sun Nov 11 19:16:37 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Sun, 11 Nov 2007 19:16:37 -0800 Subject: [ee122] ee122 project question In-Reply-To: <330471bf0711111911w3d83218bw285b2057cb1bd3d4@mail.gmail.com> References: <4737BEA6.3030603@berkeley.edu> <330471bf0711111911w3d83218bw285b2057cb1bd3d4@mail.gmail.com> Message-ID: <330471bf0711111916r79faf981i888948562deda92e@mail.gmail.com> PS, don't worry too much about this. Just use a reasonable value and maybe give a few words on why you think that value is reasonable. On Nov 11, 2007 7:11 PM, Lisa Fowler wrote: > Given that the MSS is an abstraction provided by TCP, this is > something that you should decide and provide with your protocol. You > may think of these things as "if TCP is the protocol that provides a > particular feature and no other underlying protocol provides that > feature, I should have to provide that feature in my > replacement-for-TCP protocol." > > -Lisa > > > On Nov 11, 2007 6:47 PM, Michael Ngo wrote: > > How do you determine the MSS of the interface from which I am sending > > to? This is to set an initial value for the receiver's buffer size. > > > > Michael Ngo > > _______________________________________________ > > ee122 mailing list > > ee122 at mailman.ICSI.Berkeley.EDU > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > > From ee122-dm at imail.EECS.Berkeley.EDU Sun Nov 11 20:39:42 2007 From: ee122-dm at imail.EECS.Berkeley.EDU (ee122-dm at imail.EECS.Berkeley.EDU) Date: Sun, 11 Nov 2007 20:39:42 -0800 (PST) Subject: [ee122] Project 2 partner Message-ID: <4185.67.102.22.242.1194842382.squirrel@imail.eecs.berkeley.edu> Sorry to post again so quickly, but I've found a partner. -Aaron From lingchen at berkeley.edu Mon Nov 12 02:21:15 2007 From: lingchen at berkeley.edu (Ling Chen) Date: Mon, 12 Nov 2007 02:21:15 -0800 Subject: [ee122] Project 2 partner In-Reply-To: <4185.67.102.22.242.1194842382.squirrel@imail.eecs.berkeley.edu> References: <4185.67.102.22.242.1194842382.squirrel@imail.eecs.berkeley.edu> Message-ID: <4738291B.6040500@berkeley.edu> My partner left me for her old partner. So now I'm looking for another partner. If anyone out there is still alone... Reply me. I can code in C or C++. Thanks. From ee105-da at imail.eecs.berkeley.edu Mon Nov 12 02:16:53 2007 From: ee105-da at imail.eecs.berkeley.edu (Sunflower) Date: Mon, 12 Nov 2007 02:16:53 -0800 Subject: [ee122] Project 2 Partner Message-ID: <47382815.4040805@imail.eecs.berkeley.edu> My partner left me for her old partner. So now I'm looking for another partner. If anyone out there is still alone... Reply me. I can code in C or C++. From apolloellis at berkeley.edu Mon Nov 12 20:49:42 2007 From: apolloellis at berkeley.edu (apolloellis at berkeley.edu) Date: Mon, 12 Nov 2007 20:49:42 -0800 (PST) Subject: [ee122] Project 2 Partner Message-ID: <3287.69.107.97.8.1194929382.squirrel@calmail.berkeley.edu> Hi in reply to the previous post. I also don't have a partner and wouldn't mind partnering up at this point. If you are interested give me an email at apolloellis at berkeley.edu. Apollo From fowler at eecs.berkeley.edu Mon Nov 12 21:49:33 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Tue, 13 Nov 2007 00:49:33 -0500 Subject: [ee122] Lisa not available 10am-10pm tomorrow Message-ID: <330471bf0711122149t23c96129u5f9ba0c14f1bc210@mail.gmail.com> I apologize to the last-minute folks, but I will be stuck in an airplane or transit related vehicles/establishments from 10am-10pm tomorrow and will thus not be available to answer specific questions during that time. If you have questions, ask them tonight and I will respond in the morning, or ask them later to the list or directly to Professor Paxson. With the power of the Internet on my phone, I will be able to answer **SHORT** questions when I'm in an airport at around 4-5pm, so feel free to send me short non-time-critical questions. I've answered a few questions already on the list and to people in private. Here are some frequently asked questions: * Do headers have to be word-aligned? -- Not necessarily, but argue your stance. * Do we need checksums? -- If you decide you want or need a checksum, don't kill yourself with the math. A parity bit is sufficient. * If such-and-such is provided by an underlying layer, and we want to use that pre-existing feature, can we? -- Yes. * How detailed do our FSMs need to be? -- As detailed as necessary. Feel free to have several at different "granularities". -Lisa From kristianlyngbaek at berkeley.edu Tue Nov 13 01:50:31 2007 From: kristianlyngbaek at berkeley.edu (Kristian Lyngbaek) Date: Tue, 13 Nov 2007 01:50:31 -0800 Subject: [ee122] Very Last Minute Project 2 Question Message-ID: <8d5ba94f0711130150j4d11a883wd54c6684222d10e0@mail.gmail.com> I was wondering if we were supposed to explicitly describe our congestion and flow control mechanisms. I mentioned them while explaining the other parts of the project, but the project guidelines don't mention anything about flow/congestions control. They seem like important pieces of the protocol, so do we need to describe exactly how they work in words or is following the prompts in the guidelines sufficient? Thank in advance, Kristian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071113/3d30aad1/attachment.html From fowler at eecs.berkeley.edu Tue Nov 13 06:07:12 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Tue, 13 Nov 2007 09:07:12 -0500 Subject: [ee122] Very Last Minute Project 2 Question In-Reply-To: <8d5ba94f0711130150j4d11a883wd54c6684222d10e0@mail.gmail.com> References: <8d5ba94f0711130150j4d11a883wd54c6684222d10e0@mail.gmail.com> Message-ID: <330471bf0711130607g7d24c462l8fcd5a1f5c49cd9a@mail.gmail.com> They should be explicitly described. -Lisa On Nov 13, 2007 4:50 AM, Kristian Lyngbaek wrote: > I was wondering if we were supposed to explicitly describe our congestion > and flow control mechanisms. I mentioned them while explaining the other > parts of the project, but the project guidelines don't mention anything > about flow/congestions control. They seem like important pieces of the > protocol, so do we need to describe exactly how they work in words or is > following the prompts in the guidelines sufficient? > > Thank in advance, Kristian > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > From fowler at eecs.berkeley.edu Wed Nov 14 10:10:40 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Wed, 14 Nov 2007 10:10:40 -0800 Subject: [ee122] p2p1 submissions Message-ID: <330471bf0711141010l541b525eja978f7e7e65e86fb@mail.gmail.com> I have ACKed what I've received so far. If you heard no ACK (e.g. "Got it!"), I haven't received it. If you emailed or dropped off a doc, please check to see that you got a confirmation. Thanks, Lisa From fowler at eecs.berkeley.edu Fri Nov 16 13:25:11 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Fri, 16 Nov 2007 13:25:11 -0800 Subject: [ee122] "Unidirectional" connections Message-ID: <330471bf0711161325v21fa4ae6id5be1124cbe400ac@mail.gmail.com> Hi all- Your graded phase 1s should be coming to you within the next 24 hours. In the meanwhile, please take the time to think about and argue to yourself why a three-way handshake in connection establishment is no longer necessary. I spent a good portion of my office hours discussing this matter today and I would really like for you to understand why it's not necessary/applicable in the unidirectional case. Think about this. If you have questions, email me and let's set up a time to talk about it before you move forward with your project. Understanding this detail will help to better frame the rest of the project, even if you still choose to do something else during connection establishment. It's the concept that I want you to have down pat. -Lisa From davide.cerri at gmail.com Fri Nov 16 13:29:24 2007 From: davide.cerri at gmail.com (Davide Cerri) Date: Fri, 16 Nov 2007 13:29:24 -0800 Subject: [ee122] question about buffer Message-ID: Hello, how do we handle the buffer? I mean, we have our windowsize, and whenever we receive a packet, we free the window slot and we copy the data to some buffer. Whenever somebody calls myreceive, we return the content of that buffer. Here's the questions: 1 - do we return the content of the buffer if and only if we received all the packages, so the buffer is not a partial transmission? 2 - what do we do if somebody is sending a crazy amount of data (ex 1tb)? that can't obviously be stored in a buffer? thanks -- ~/Davide Cerri From fowler at eecs.berkeley.edu Fri Nov 16 13:32:33 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Fri, 16 Nov 2007 13:32:33 -0800 Subject: [ee122] question about buffer In-Reply-To: References: Message-ID: <330471bf0711161332j48277364vb35d964d14897d7@mail.gmail.com> On Nov 16, 2007 1:29 PM, Davide Cerri wrote: > Hello, > how do we handle the buffer? > I mean, we have our windowsize, and whenever we receive a packet, we > free the window slot and we copy the data to some buffer. Whenever > somebody calls myreceive, we return the content of that buffer. > Here's the questions: > 1 - do we return the content of the buffer if and only if we received > all the packages, so the buffer is not a partial transmission? That's up to you. You want it to be as close to how TCP worked (rather, what your HTTP server/client expects). TCP doesn't necessarily provide everything all at once, and neither do you. > 2 - what do we do if somebody is sending a crazy amount of data (ex > 1tb)? that can't obviously be stored in a buffer? That's what flow control is for :) Use it with the above notion. -Lisa From fowler at eecs.berkeley.edu Fri Nov 16 16:45:12 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Fri, 16 Nov 2007 16:45:12 -0800 Subject: [ee122] Project 2 (p)Review Session Message-ID: <330471bf0711161645m7089d299k70d10d01db143203@mail.gmail.com> I'm waiting for confirmation for a room in Soda from 11:30am-12:30pm on Monday. The room looks available, but the people who officially handle the reservations might have gone home already so I won't be confirmed until Monday morning. I'll let you know where to be on Monday morning, but the time will be 11:30-12:30pm. (I do have a backup room.) Please be prompt as I won't be able to go past 12:30pm. -Lisa From huntingtonsurfca at gmail.com Sun Nov 18 20:09:00 2007 From: huntingtonsurfca at gmail.com (Richard Schmidt) Date: Sun, 18 Nov 2007 20:09:00 -0800 Subject: [ee122] Scaling down Proj1 Message-ID: Hello, I think it would be helpful in knowing how much we can simplify our previous project in order to facilitate the emphasis on the inter-protocol. What I would like to do: (Outline) - Throw out data structure for keeping multiple connections. - Use 'listener' as a valid socket for recieving initial data (ala FTP). - Static number of sockets total. - Sequential handling of interactions (no sending_data until all data_recieve'd). - No persistent connections. The spec mentions some parts that can be tossed, but I'd like to know if there's a limit on how far I can simplify the interactions and still create an acceptable atomosphere for our protocol to work under. Basically I want to model the interactions as we normally do in the homework. Rick From fowler at eecs.berkeley.edu Sun Nov 18 21:22:33 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Sun, 18 Nov 2007 21:22:33 -0800 Subject: [ee122] Scaling down Proj1 In-Reply-To: References: Message-ID: <330471bf0711182122t12a19332ub8e7a3e431e49c09@mail.gmail.com> I'm sorry it wasn't clear before, but I do mean that the inclusion of Project 1 code in Project 2 is so that you have something that can trivially request and then transfer a single file from one host to the other. I *really* don't care about anything else. As long as you can still have host A request a file from host B (via a plain vanilla GET request for a file in the working directory), and have host B send the requested file to host A, that's great. That's all I'm looking for. One host A, one host B, and the ability to request and transfer a particular file. Your priority is showing that your protocol abstracts away all the underlying work and helps create the illusion of a reliable in-order channel, no matter the loss, delay, corruption, etc. seen below. The app's view of (i.e. interface to) your transport protocol should be nearly identical to how it was before when using TCP. -Lisa On Nov 18, 2007 8:09 PM, Richard Schmidt wrote: > Hello, > > I think it would be helpful in knowing how much we can simplify our > previous project in order to facilitate the emphasis on the > inter-protocol. > > What I would like to do: (Outline) > > - Throw out data structure for keeping multiple connections. > - Use 'listener' as a valid socket for recieving initial data (ala FTP). > - Static number of sockets total. > - Sequential handling of interactions (no sending_data until all > data_recieve'd). > - No persistent connections. > > The spec mentions some parts that can be tossed, but I'd like to know > if there's a limit on how far I can simplify the interactions and > still create an acceptable atomosphere for our protocol to work under. > Basically I want to model the interactions as we normally do in the > homework. > > Rick > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From lingchen at berkeley.edu Mon Nov 19 03:17:59 2007 From: lingchen at berkeley.edu (Ling Chen) Date: Mon, 19 Nov 2007 03:17:59 -0800 Subject: [ee122] Project 2 Review Message-ID: <474170E7.4060505@berkeley.edu> Do we have a confirmation on a room yet? If so, which room? If not, where is the backup room? Ling From fowler at eecs.berkeley.edu Mon Nov 19 08:49:46 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Mon, 19 Nov 2007 08:49:46 -0800 Subject: [ee122] Proj 2 Review Today Soda 320 Message-ID: <330471bf0711190849l23d9926by9760206ac6e7e88b@mail.gmail.com> Soda 320 11:30-12:30pm. This is not a one-on-one meeting nor an ask-Lisa-why-she-took-points-off meeting, but just to help clarify what unidirectional transport means in terms of your protocol. It'd be valuable if you didn't understand exactly how the non-three-way-handshake applies in this case (and it's subtle!!) See you then! -Lisa From fowler at eecs.berkeley.edu Mon Nov 19 14:48:52 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Mon, 19 Nov 2007 14:48:52 -0800 Subject: [ee122] P2 FAQ Message-ID: <330471bf0711191448o7ea45a93ud13531e045e7d83b@mail.gmail.com> For your ease of reference, http://www.eecs.berkeley.edu/~fowler/ee122/fa07/proj2faq.html Ta-da! -Lisa From jeremyfleischman at berkeley.edu Mon Nov 19 21:28:45 2007 From: jeremyfleischman at berkeley.edu (Jeremy Fleischman) Date: Mon, 19 Nov 2007 21:28:45 -0800 Subject: [ee122] Proj2B Multiple Connections? Message-ID: <5830e3770711192128v1a2ca1c6sfc09835d83f2d5f0@mail.gmail.com> Does our implementation of a reliable transfer protocol need to deal with multiple senders and receivers? In other words, should we provide exactly four methods (connect(), send(), recv(), and close()) that provide exactly the same behavior as TCP? Or can we assume for example, that connect() only gets called once? Jeremy Fleischman From a_kilman at berkeley.edu Mon Nov 19 23:24:34 2007 From: a_kilman at berkeley.edu (Anthony Kilman) Date: Mon, 19 Nov 2007 23:24:34 -0800 Subject: [ee122] Network byte ordering functions... Message-ID: <1195543474.30197.2.camel@zero.cool> Quick question.. Is there such a thing as htonc() [host to network (8-bit)char]? If not, what is the easiest way to determine the "endian-ness" of the machine? Thanks in advance. Anthony From dank at eecs.berkeley.edu Tue Nov 20 00:28:38 2007 From: dank at eecs.berkeley.edu (Daniel Killebrew) Date: Tue, 20 Nov 2007 00:28:38 -0800 Subject: [ee122] Network byte ordering functions... In-Reply-To: <1195543474.30197.2.camel@zero.cool> References: <1195543474.30197.2.camel@zero.cool> Message-ID: <47429AB6.6060507@eecs.berkeley.edu> Anthony Kilman wrote: > Quick question.. > > Is there such a thing as htonc() [host to network (8-bit)char]? No, most machines order the bits within a byte the same way, it's the bytes within a 16bit or 32 bit word that can be ordered differently. > If not, > what is the easiest way to determine the "endian-ness" of the machine? > If you know the processor, google. If you have access to the source of the C standard library, you could look at the source for htons(). Or write a 32 bit word to memory, then read the memory locations out a byte at a time and see what order you get them in. Daniel > Thanks in advance. > > Anthony > > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > From dank at eecs.berkeley.edu Tue Nov 20 00:36:13 2007 From: dank at eecs.berkeley.edu (Daniel Killebrew) Date: Tue, 20 Nov 2007 00:36:13 -0800 Subject: [ee122] Network byte ordering functions... In-Reply-To: <47429AB6.6060507@eecs.berkeley.edu> References: <1195543474.30197.2.camel@zero.cool> <47429AB6.6060507@eecs.berkeley.edu> Message-ID: <47429C7D.8010307@eecs.berkeley.edu> Daniel Killebrew wrote: > Anthony Kilman wrote: > >> Quick question.. >> >> Is there such a thing as htonc() [host to network (8-bit)char]? >> > No, most machines order the bits within a byte the same way, Actually, I'm not really sure about this part, but when you write bytes a a time over the network, it seems to work regardless. Daniel > it's the > bytes within a 16bit or 32 bit word that can be ordered differently. > >> If not, >> what is the easiest way to determine the "endian-ness" of the machine? >> >> > If you know the processor, google. If you have access to the source of > the C standard library, you could look at the source for htons(). Or > write a 32 bit word to memory, then read the memory locations out a byte > at a time and see what order you get them in. > > Daniel > >> Thanks in advance. >> >> Anthony >> >> _______________________________________________ >> ee122 mailing list >> ee122 at mailman.ICSI.Berkeley.EDU >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 >> >> >> > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > From vern at cs.berkeley.edu Tue Nov 20 00:40:02 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Tue, 20 Nov 2007 00:40:02 -0800 Subject: [ee122] Network byte ordering functions... In-Reply-To: <47429AB6.6060507@eecs.berkeley.edu> (Tue, 20 Nov 2007 00:28:38 PST). Message-ID: <200711200840.lAK8e7SR002953@pork.ICSI.Berkeley.EDU> > Or > write a 32 bit word to memory, then read the memory locations out a byte > at a time and see what order you get them in. Even easier (well, perhaps cheating :-) is just compare along the lines of if ( 1234 == htonl(1234) ) /* We must be on a big-endian machine ... */ - Vern From vern at cs.berkeley.edu Tue Nov 20 00:48:04 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Tue, 20 Nov 2007 00:48:04 -0800 Subject: [ee122] Proj2B Multiple Connections? In-Reply-To: <5830e3770711192128v1a2ca1c6sfc09835d83f2d5f0@mail.gmail.com> (Mon, 19 Nov 2007 21:28:45 PST). Message-ID: <200711200848.lAK8m9ej003524@pork.ICSI.Berkeley.EDU> For expediency, it's okay to implement it to just support a single connection, to keep things tractable. Vern From davide.cerri at gmail.com Tue Nov 20 20:10:56 2007 From: davide.cerri at gmail.com (Davide Cerri) Date: Tue, 20 Nov 2007 20:10:56 -0800 Subject: [ee122] my connect Message-ID: Hello, Do we really need to implement my connect and my_listen? We are not going to create any persistent connection nor multiple connections, so can't we just offer as api the two functions my_send and my_receive . Then if a host is client it will have a loop that starts with send followed by receive,and if the host is a server it will loop starting with receive and then send. Our protocol will just make sure that all packages are received in order, but not grant and established connection. Is this reasonable? -- ~/Davide Cerri $sudo yes | rm -Rf / From vern at cs.berkeley.edu Tue Nov 20 20:36:32 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Tue, 20 Nov 2007 20:36:32 -0800 Subject: [ee122] my connect In-Reply-To: (Tue, 20 Nov 2007 20:10:56 PST). Message-ID: <200711210436.lAL4abdZ000875@pork.ICSI.Berkeley.EDU> > Do we really need to implement my connect and my_listen? We are not > going to create any persistent connection nor multiple connections You *are* implementing a persistent connection, and its establishment needs to be reliable. This means that the receiving side needs to (first) listen, and the initiating side needs to connect. (We left off multiple connections as a simplicity of *implementation*. But conceptually your protocol should support it, which requires explicit establishment.) > Then if a host is client it will have a loop that starts with send > followed by receive,and if the host is a server it will loop starting > with receive and then send. Our protocol will just make sure that all > packages are received in order How will the server know what packet reflects the first in the connection, if that one happens to be lost? Vern From huntingtonsurfca at gmail.com Tue Nov 20 21:34:33 2007 From: huntingtonsurfca at gmail.com (Richard Schmidt) Date: Tue, 20 Nov 2007 21:34:33 -0800 Subject: [ee122] accept() concept Message-ID: I was wondering if the socket returned by accept() has the same port number on the server side of the pipe as the listener. I am trying to write my version of accept and I want to make sure that I know what's going on conecptually. Also, a lot of these send() recv() calls seem to happen under the surface of our application (where the client seems to be continuously ACK'ing packets even though they're not technically in the recv() call). Does this pose a problem, namely with RTT and timeouts? How does the normal TCP do it when we use send()/recv()? It seems like the OS handles everything for us (ACK wise). Thanks, Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071120/34724c5f/attachment.html From vern at cs.berkeley.edu Tue Nov 20 21:47:11 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Tue, 20 Nov 2007 21:47:11 -0800 Subject: [ee122] IMPORTANT - Read - Change in Project 2 (Re: accept() concept) In-Reply-To: (Tue, 20 Nov 2007 21:34:33 PST). Message-ID: <200711210547.lAL5lGSC001904@pork.ICSI.Berkeley.EDU> > I was wondering if the socket returned by accept() has the same port number > on the server side of the pipe as the listener. Yes. > Also, a lot of these send() recv() calls seem to happen under the surface of > our application (where the client seems to be continuously ACK'ing packets > even though they're not technically in the recv() call). Does this pose a > problem, namely with RTT and timeouts? How does the normal TCP do it when we > use send()/recv()? It seems like the OS handles everything for us (ACK > wise). You've homed in on a key, tricky issue. Essentially, to do this correctly, you need to have multiple threads of execution running concurrently, rather than a single one. With TCP under Unix, one thread is in the kernel and the other is the application at user-level. We have in fact decided that this is too much complexity to ask of the students by the end of the semester. Thus, we're right now revising the Project #2 writeup to reflect that for full credit, you just need to implement a sending program that transfers a file to a receiving program, and for which you can structure the program as presenting your protocol with a single (large) buffer to send, after which your protocol has the thread of execution which it can use to send timers and process incoming acks - or, on the other side, process data packets that arrive asynchronously, send acks back as needed, and collect together the entire transfer into one large buffer that it then passes back to the receiving program. You can in addition port your Project 1 Web client & server for extra credit, but it is no longer a mandatory part of the project. The revised writeup will go out either tonight or tomorrow morning. Vern From vern at cs.berkeley.edu Tue Nov 20 23:56:40 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Tue, 20 Nov 2007 23:56:40 -0800 Subject: [ee122] two important announcements Message-ID: <200711210756.lAL7uj40003655@pork.ICSI.Berkeley.EDU> (1) Homework #4 is now out, due Friday Dec 7 before lecture. (2) Per the note in the reply I sent earlier to the mailing list, we have simplified the requirements for Project #2. The writeup has been revised to state that you just need to implement a sending program that simply transfers a file to a receiving program, and this can be done by the sender collecting together the entire file in a buffer that it passes to your transport protocol in a single call, and your transport protocol on the receiver side making available the entire contents as a value returned from a single call. You can in addition port your Project 1 Web client & server for extra credit, but this is no longer a mandatory part of the project. - Vern From jeremyfleischman at berkeley.edu Wed Nov 21 04:15:56 2007 From: jeremyfleischman at berkeley.edu (Jeremy Fleischman) Date: Wed, 21 Nov 2007 04:15:56 -0800 Subject: [ee122] UDP's recvfrom() abstraction Message-ID: <5830e3770711210415w55e465aete19740059b1ef83c@mail.gmail.com> TCP provides us with a guaranteed stream of data. This makes things tricky for a TCP receiver in cases where we need to separate two messages a receiver sends us. For example, if the server sends us the message "hi" and then "how are you", all the receiver will eventually get is "hi how are you". But it is possible that the sender was saying hello to an old friend of his named "how", and was then going to ask him "are you doing your ee122 project". It is easier to see the two possibilities with punctuation. Hi how are you?... OR Hi How. Are you doing your ee122 project? This problem is dealt with using the computer science equivalent of punctuation, delimiters. Remember good 'ol ? My understanding is that UDP does not abstract away the underlying packets to be a stream of data, as it doesn't make much sense for a stream to be arbitrarily cut and twisted upon itself. But Beej's guide says that we use recvfrom() to receive data over UDP. The arguments to recvfrom() are the same as recv() except for the addition of two arguments specifying the sender to receive from. So my question is this: if the sender sends us two distinct UDP packets like this: "hi how", "are you doing your ee122 project" and we call recvfrom() asking for something like 100 bytes, could we get this: "hi how are you doing your ee122 project" or maybe "hi how" or maybe just "hi"? It doesn't make sense to concatenate the two packets ("hi how are you doing your ee122 project"), and it doesn't make sense to receive part of a packet either ("hi") as packets either make it entirely or are dropped. This same question applies to the sender side as well. Will two calls to UDP's sendto() always result in two UDP packets? sendto() returns an int specifying the number of bytes sent. So, if I want to send the message "hi how are you ", and I call sendto() with this buffer, but sendto() returns 3, all I've done is send the message "hi " out on a UDP packet. I would then call sento() again, and it may return 4, which means that I sent "how " out on a packet. I finally call sendto() one more time, and it returns 8, meaning I've sent out "are you " (the rest of my message). But let's say that the packet "hi " gets dropped, and the other 2 packets get reordered, which means that the receiver could potentially receive the packet "are you " and then "how ", which makes the message appear to be questioning if your name is "how", as opposed to the salutations it was meant to be. I hope I have been clear in my discussion of the problems I fear could arise using UDP's sendto() and recvfrom(). I feel that the problem that arises if sendto() sends only part of your message is impossible to fix without lower level control where we construct the UDP packets ourselves. Jeremy Fleischman From fowler at eecs.berkeley.edu Wed Nov 21 09:25:17 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Wed, 21 Nov 2007 09:25:17 -0800 Subject: [ee122] UDP's recvfrom() abstraction In-Reply-To: <5830e3770711210415w55e465aete19740059b1ef83c@mail.gmail.com> References: <5830e3770711210415w55e465aete19740059b1ef83c@mail.gmail.com> Message-ID: <330471bf0711210925m2472872v3ce1777433d5d88a@mail.gmail.com> I think you're getting a little confused in layering... Let me try to explain a possible approach and let me know if this is not what you're looking for: >From a slide from the "Moves Institute": Many OS's have memory limits on their input buffers that limit default incoming UDP packets to 8192 bytes. Any host must take at least 512 bytes. You can fiddle with this to some extent. As a general rule, don't go over 1500 bytes, because that's a popular ethernet MTU. Most will be well below that. Moral: try not to fragment UDP packets So what does this mean to you? It means that your MSS value that you picked before will be pretty important. You want to stay within a packet-size, which will be somewhere between 512B and 1500B. Code-wise, you will have to control how much you send in one given sendto(). Set that value (the 3rd index -- size_t len) to be your MSS. On your receiving end, set your receive length to be your MSS (again, the 3rd index -- size_t len). Your *app* will (since you want to create the stream abstraction) "just" call my_send(). Within my_send(), you should have a loop that breaks the larger application data unit or application message into MSS-sized packets and sends those individually. Each of those packets should have the custom header. (each call to sendto() generates a single UDP packet) On the other side, my_recv() would do a similar loop, reconstructing the application message from those MSS-sized packets. Let me know if that doesn't answer your question. Lisa On Nov 21, 2007 4:15 AM, Jeremy Fleischman wrote: > TCP provides us with a guaranteed stream of data. This makes things > tricky for a TCP receiver in cases where we need to separate two > messages a receiver sends us. For example, if the server sends us the > message "hi" and then "how are you", all the receiver will eventually > get is "hi how are you". But it is possible that the sender was saying > hello to an old friend of his named "how", and was then going to ask > him "are you doing your ee122 project". > It is easier to see the two possibilities with punctuation. > Hi how are you?... OR Hi How. Are you doing your ee122 project? > > This problem is dealt with using the computer science equivalent of > punctuation, delimiters. Remember good 'ol ? > > My understanding is that UDP does not abstract away the underlying > packets to be a stream of data, as it doesn't make much sense for a > stream to be arbitrarily cut and twisted upon itself. But Beej's guide > says that we use recvfrom() to receive data over UDP. The arguments to > recvfrom() are the same as recv() except for the addition of two > arguments specifying the sender to receive from. So my question is > this: if the sender sends us two distinct UDP packets like this: > "hi how", "are you doing your ee122 project" > and we call recvfrom() asking for something like 100 bytes, could we > get this: "hi how are you doing your ee122 project" or maybe "hi how" > or maybe just "hi"? It doesn't make sense to concatenate the two > packets ("hi how are you doing your ee122 project"), and it doesn't > make sense to receive part of a packet either ("hi") as packets either > make it entirely or are dropped. > > This same question applies to the sender side as well. Will two calls > to UDP's sendto() always result in two UDP packets? sendto() returns > an int specifying the number of bytes sent. So, if I want to send the > message "hi how are you ", and I call sendto() with this buffer, but > sendto() returns 3, all I've done is send the message "hi " out on a > UDP packet. I would then call sento() again, and it may return 4, > which means that I sent "how " out on a packet. I finally call > sendto() one more time, and it returns 8, meaning I've sent out "are > you " (the rest of my message). But let's say that the packet "hi " > gets dropped, and the other 2 packets get reordered, which means that > the receiver could potentially receive the packet "are you " and then > "how ", which makes the message appear to be questioning if your name > is "how", as opposed to the salutations it was meant to be. > > I hope I have been clear in my discussion of the problems I fear could > arise using UDP's sendto() and recvfrom(). I feel that the problem > that arises if sendto() sends only part of your message is impossible > to fix without lower level control where we construct the UDP packets > ourselves. > > Jeremy Fleischman > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From vern at cs.berkeley.edu Wed Nov 21 10:26:14 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Wed, 21 Nov 2007 10:26:14 -0800 Subject: [ee122] UDP's recvfrom() abstraction In-Reply-To: <5830e3770711210415w55e465aete19740059b1ef83c@mail.gmail.com> (Wed, 21 Nov 2007 04:15:56 PST). Message-ID: <200711211826.lALIQJna016341@pork.ICSI.Berkeley.EDU> > So my question is > this: if the sender sends us two distinct UDP packets like this: > "hi how", "are you doing your ee122 project" > and we call recvfrom() asking for something like 100 bytes, could we > get this: "hi how are you doing your ee122 project" or maybe "hi how" > or maybe just "hi"? No. You'll receive them as distinct packets, assuming they haven't been lost. They might arrive out of order, however. > This same question applies to the sender side as well. Will two calls > to UDP's sendto() always result in two UDP packets? Yes, if by UDP's sendto() you mean sendto() using a socket of type SOCK_DGRAM. > So, if I want to send the > message "hi how are you ", and I call sendto() with this buffer, but > sendto() returns 3 It won't for SOCK_DGRAM. Vern From davide.cerri at gmail.com Wed Nov 21 16:36:04 2007 From: davide.cerri at gmail.com (Davide Cerri) Date: Wed, 21 Nov 2007 16:36:04 -0800 Subject: [ee122] question about winsize and ack in tcp Message-ID: Hello, 1 - if i advertise a window size of zero will the other side of the connection stop to send packages? 2 - if i have a window size that can fit 5 packages and i receive packet 1 2 4 5, when i send the second duplicate ack, do i advertise a windowsize of 0 or of 1 ? 3 - is it correct to always try to send the min(CWND, windowsize)? Thanks. -- ~/Davide Cerri $sudo yes | rm -Rf / From fowler at eecs.berkeley.edu Wed Nov 21 16:40:37 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Wed, 21 Nov 2007 16:40:37 -0800 Subject: [ee122] question about winsize and ack in tcp In-Reply-To: References: Message-ID: <330471bf0711211640i7154f6d8p676318f00f44a1d2@mail.gmail.com> On Nov 21, 2007 4:36 PM, Davide Cerri wrote: > Hello, > 1 - if i advertise a window size of zero will the other side of the > connection stop to send packages? It depends on your design and implementation.... > 2 - if i have a window size that can fit 5 packages and i receive > packet 1 2 4 5, when i send the second duplicate ack, do i advertise a > windowsize of 0 or of 1 ? If your client has a buffer size of 5, it should advertise a window size of 1 because that's what it has available at that moment. > 3 - is it correct to always try to send the min(CWND, windowsize)? ? In TCP, that's what happens, so it's correct in TCP. -Lisa From vern at cs.berkeley.edu Wed Nov 21 18:19:49 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Wed, 21 Nov 2007 18:19:49 -0800 Subject: [ee122] question about winsize and ack in tcp In-Reply-To: (Wed, 21 Nov 2007 16:36:04 PST). Message-ID: <200711220219.lAM2Jssr024248@pork.ICSI.Berkeley.EDU> > 1 - if i advertise a window size of zero will the other side of the > connection stop to send packages? Yes. (The other side still might retransmit data that's below what's been acknowledged, if it hasn't received the acknowledgments.) (Note, there's an issue which is how does the other side start sending again. Clearly, it needs to receive a "window update" acknowedgment that now advertises a window > 0. TCP sends these whenever it finds that it now has some buffer space available. However, acks are *not* reliably delivered, so in fact the sender might not receive this and remain hung. Because of this, TCP actually has a mechanism termed "zero window probe" by which the sender essentially asks the receiver "is the window really still zero?". But this is a detail we haven't covered.) > 2 - if i have a window size that can fit 5 packages and i receive > packet 1 2 4 5, when i send the second duplicate ack, do i advertise a > windowsize of 0 or of 1 ? The window size is always with respect to what's being acknowledged. So in this case the acks would all be for packet 2 and would advertise a window of 5, since the receiver doesn't have to buffer 1 or 2 any more, and so can accept up to 7. > 3 - is it correct to always try to send the min(CWND, windowsize)? Yes, that's how TCP determines it's current sending window, per the pseudo-code sent to the list a little while ago. Vern From davide.cerri at gmail.com Fri Nov 23 18:06:04 2007 From: davide.cerri at gmail.com (Davide Cerri) Date: Fri, 23 Nov 2007 18:06:04 -0800 Subject: [ee122] sendto and recvfrom Message-ID: Hello, I don't understand how to establish a permanent connection. As a client we create a socket and we return a fd. After that step the client set the ip address and port of the server to establish a connection. from that structure that is passed in connect we can extract the information about the server. so we can use sentto to communicate with the server. The server receives the message with recvfrom (since there is no accept in udp). Here's my 2 questions: 1 - if the server side receives with recvfrom, do we need to know the address of the sender a priori? and if it so how can the server side obtain that information? 2 - If the client cannot specify the port that is sending from, how can we communicate which port are using to the server? are we assured that once we create a socket the socket will be always connected to the same port? can we bind (UDP) sockets? the man pages usually specify which type of sockets can use specific functions (ex. listen), but for bind there is no specification, and i am assuming that every socket need to be able to be bind() to a specific port if we want to be able to advertise that port for incoming messages. Still after we call bind() on a socket, if we use recvfrom() then we need to know who is ending the message. 3 - How can we use a UDP socket to receive messages from any user? thanks -- ~/Davide Cerri $sudo yes | rm -Rf / From davide.cerri at gmail.com Fri Nov 23 18:22:06 2007 From: davide.cerri at gmail.com (Davide Cerri) Date: Fri, 23 Nov 2007 18:22:06 -0800 Subject: [ee122] recvfrom() Message-ID: Hello, sorry for the last post. I misunderstood recvfrom(). Recvfrom() takes a address structure where it writes the info about who sent the message. I thought that we would have to fill in that data ourselves. I hope i got it right this time. Also, does anybody understand the difference between recvfrom() and recvmsg()? thanks -- ~/Davide Cerri $sudo yes | rm -Rf / From fowler at eecs.berkeley.edu Fri Nov 23 19:01:28 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Fri, 23 Nov 2007 19:01:28 -0800 Subject: [ee122] recvfrom() In-Reply-To: References: Message-ID: <330471bf0711231901u946f32fse370868ab8eccb17@mail.gmail.com> On Nov 23, 2007 6:22 PM, Davide Cerri wrote: > Hello, > sorry for the last post. I misunderstood recvfrom(). Recvfrom() takes > a address structure where it writes the info about who sent the > message. I thought that we would have to fill in that data ourselves. > I hope i got it right this time. > > Also, does anybody understand the difference between recvfrom() and recvmsg()? Here is some info about recvmsg, namely regarding its security. It might help in clarifying the differences between the two: https://buildsecurityin.us-cert.gov/daisy/bsi-rules/home/g1/811.html There's a lot of info in the manpage on recvfrom, recv, and recvmsg regarding their features, but I think the above link has some interesting stuff. -Lisa From apolloellis at berkeley.edu Fri Nov 23 20:48:55 2007 From: apolloellis at berkeley.edu (apolloellis at berkeley.edu) Date: Fri, 23 Nov 2007 20:48:55 -0800 (PST) Subject: [ee122] mnl not found on server Message-ID: <3605.69.107.109.88.1195879735.squirrel@calmail.berkeley.edu> Are the mnl tar and the p2files not on the server right now? I can't access them. Apollo From fowler at eecs.berkeley.edu Fri Nov 23 20:51:53 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Fri, 23 Nov 2007 20:51:53 -0800 Subject: [ee122] mnl not found on server In-Reply-To: <3605.69.107.109.88.1195879735.squirrel@calmail.berkeley.edu> References: <3605.69.107.109.88.1195879735.squirrel@calmail.berkeley.edu> Message-ID: <330471bf0711232051r3c0a76f7t29ac5e940d451d1e@mail.gmail.com> On Nov 23, 2007 8:48 PM, wrote: > Are the mnl tar and the p2files not on the server right now? I can't > access them. Sorry, the file hasn't moved yet. You can find it at its old location for the time-being: http://inst.eecs.berkeley.edu/~ee122/fa06/projects/MNL_0_1a.tar.gz -Lisa > Apollo > > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From apolloellis at berkeley.edu Fri Nov 23 21:03:46 2007 From: apolloellis at berkeley.edu (apolloellis at berkeley.edu) Date: Fri, 23 Nov 2007 21:03:46 -0800 (PST) Subject: [ee122] checksum error Message-ID: <3631.69.107.109.88.1195880626.squirrel@calmail.berkeley.edu> I used: tar xvf MNL_0_ls.tar.gz and got directory checksum error. Any help? Apollo From vern at cs.berkeley.edu Fri Nov 23 21:23:30 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Fri, 23 Nov 2007 21:23:30 -0800 Subject: [ee122] checksum error In-Reply-To: <3631.69.107.109.88.1195880626.squirrel@calmail.berkeley.edu> (Fri, 23 Nov 2007 21:03:46 PST). Message-ID: <200711240523.lAO5NZDx007742@pork.ICSI.Berkeley.EDU> > I used: tar xvf MNL_0_ls.tar.gz and got directory checksum error. Any help? Use tar xvfz - z = compressed, per the .gz suffix. Vern From vern at cs.berkeley.edu Fri Nov 23 21:32:27 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Fri, 23 Nov 2007 21:32:27 -0800 Subject: [ee122] mnl not found on server In-Reply-To: <330471bf0711232051r3c0a76f7t29ac5e940d451d1e@mail.gmail.com> (Fri, 23 Nov 2007 20:51:53 PST). Message-ID: <200711240532.lAO5WX2a007817@pork.ICSI.Berkeley.EDU> > Sorry, the file hasn't moved yet. You can find it at its old location > for the time-being: It's now available at http://inst.eecs.berkeley.edu/~ee122/fa07/projects/MNL_0_1a.tar.gz per the writeup. Vern From davide.cerri at gmail.com Sun Nov 25 11:27:51 2007 From: davide.cerri at gmail.com (Davide Cerri) Date: Sun, 25 Nov 2007 11:27:51 -0800 Subject: [ee122] listen() Message-ID: Hello, i am not sure about listen(). In real tcp, we set a listener, and then we rely on select to know when to call accept. So how are we going to implement listen? are we just gonna bind a port and mark it somehow as a listener? Also, since our system is not running at kernel level, can we use select the same way we did before, so that the user will call accept only when there is something in the buffer? My problem here is that the fd i return to the user is not a real fd, but a number that is used by my functions to store information about the socket. Do i have to create a my_select? and if that's the case can i just write an easy wrap around the real select? thanks -- ~/Davide Cerri $sudo yes | rm -Rf / From fowler at eecs.berkeley.edu Sun Nov 25 11:39:17 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Sun, 25 Nov 2007 11:39:17 -0800 Subject: [ee122] listen() In-Reply-To: References: Message-ID: <330471bf0711251139w5dca56a0g7eda666ad3a4bb48@mail.gmail.com> On Nov 25, 2007 11:27 AM, Davide Cerri wrote: > Hello, > i am not sure about listen(). In real tcp, we set a listener, and then > we rely on select to know when to call accept. So how are we going to > implement listen? are we just gonna bind a port and mark it somehow as > a listener? My understanding of these methods (and I'm sure Prof Paxson will correct me if I'm wrong), is that listen() examines the socket, looking for incoming SYNs. It doesn't respond to the SYNs but leaves them as half-open connections (in state SYN-RECEIVED). You can specify how many you wish to have pending using listen. accept() handles the rest of the handshake and moves the TCP connection into the ESTABLISHED state. > Also, since our system is not running at kernel level, can we use > select the same way we did before, so that the user will call accept > only when there is something in the buffer? My problem here is that > the fd i return to the user is not a real fd, but a number that is > used by my functions to store information about the socket. Do i have > to create a my_select? and if that's the case can i just write an easy > wrap around the real select? Given what you just described in your system, you should create a my_select wrapper around select. -Lisa From vern at cs.berkeley.edu Sun Nov 25 18:25:05 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Sun, 25 Nov 2007 18:25:05 -0800 Subject: [ee122] listen() In-Reply-To: (Sun, 25 Nov 2007 11:27:51 PST). Message-ID: <200711260225.lAQ2PAMO022009@pork.ICSI.Berkeley.EDU> > i am not sure about listen(). In real tcp, we set a listener, and then > we rely on select to know when to call accept. So how are we going to > implement listen? are we just gonna bind a port and mark it somehow as > a listener? First, let's review how this works for TCP: listen() is used to inform the kernel that your application is running as a server and the kernel should accept connections on its behalf. It is separate from accept() so that the kernel can accept and queue multiple connections without the application having to immediately deal with them (this is why listen() takes a queue length as an argument). listen() is applicable for TCP sockets but not for UDP, because there's no connection-acceptance activity required by the kernel for UDP servers receiving requests. Once your application calls listen(), the kernel now knows that if an incoming SYN arrives for your server, it should reply with a SYN-ACK in an attempt to establish a connection. If the corresponding ACK-SYN-ACK arrives completing the threeway handshake, then the kernel marks the socket as ready for "accept", and a subsequent call to accept() by your process will return it. For your transport protocol, in general you would want some way for the responder side of the connection (which receives the one-way transfer, and because it's a responder is termed a "server" even though it doesn't itself transmit data) to tell the kernel "yes, I want to accept incoming connections." However, because we've said you don't in fact need to support multiple simultaneous connections, your protocol implementation in fact doesn't need to worry about managing multiple arriving connections. Therefore you can combine listen() and accept() into a single call, say wait_for_new_connection(). > Also, since our system is not running at kernel level, can we use > select the same way we did before, so that the user will call accept > only when there is something in the buffer? Because you don't have to support multiple simultaneous connections, you won't in fact need to interface with select(). > My problem here is that > the fd i return to the user is not a real fd, but a number that is > used by my functions to store information about the socket. Do i have > to create a my_select? and if that's the case can i just write an easy > wrap around the real select? If you have your own type of file descriptor (which makes sense for this project, since you're not implementing in the kernel), then in fact no, it's not easy to wrap that around the real select(), which is one of the reasons why we've decided to limit the project to a single connection at a time. Vern From vern at cs.berkeley.edu Sun Nov 25 18:28:21 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Sun, 25 Nov 2007 18:28:21 -0800 Subject: [ee122] listen() In-Reply-To: <330471bf0711251139w5dca56a0g7eda666ad3a4bb48@mail.gmail.com> (Sun, 25 Nov 2007 11:39:17 PST). Message-ID: <200711260228.lAQ2SQHW022045@pork.ICSI.Berkeley.EDU> > My understanding of these methods (and I'm sure Prof Paxson will > correct me if I'm wrong), is that listen() examines the socket, > looking for incoming SYNs. It doesn't respond to the SYNs but leaves > them as half-open connections (in state SYN-RECEIVED). Almost. It does in fact respond to the SYNs, per my previous note. This is necessary to ensure that any time the listen socket shows a new connection available via accept(), it's guaranteed that there is indeed a connection available, meaning that a 3-way TCP handshake has completed. > accept() > handles the rest of the handshake and moves the TCP connection into > the ESTABLISHED state. If accept() dealt with the rest of the handshake, then it would need a way to indicate that the handshake failed. The return codes from the API don't include this (though they could've, so what you sketch would make for a reasonable design). Vern From huntingtonsurfca at gmail.com Sun Nov 25 22:47:49 2007 From: huntingtonsurfca at gmail.com (Richard Schmidt) Date: Sun, 25 Nov 2007 22:47:49 -0800 Subject: [ee122] gathering info with random unused ports (sin_port == 0) Message-ID: So Beej told me that if I want to bind a socket to a random port number, I can just set the sAddr_in.port to 0. Then the kernel will decide which port that is. >From there, though, how do I figure out what port the kernel chose? Did it overwrite the value? Is there a function analogous to getpeername() where the struct gets filled in with info? I need to advertise the second (incoming on the initiator side) socket to the reciever if he is intending to send things back, but I can't find where to get my random port number for the socket I'm using. Thanks, Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071125/21e61594/attachment.html From vern at cs.berkeley.edu Sun Nov 25 23:16:28 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Sun, 25 Nov 2007 23:16:28 -0800 Subject: [ee122] gathering info with random unused ports (sin_port == 0) In-Reply-To: (Sun, 25 Nov 2007 22:47:49 PST). Message-ID: <200711260716.lAQ7GXe6025098@pork.ICSI.Berkeley.EDU> > From there, though, how do I figure out what port the kernel chose? Did it > overwrite the value? Is there a function analogous to getpeername() where > the struct gets filled in with info? Yes, see getsockname(). > I need to advertise the second (incoming on the initiator side) socket to > the reciever if he is intending to send things back, but I can't find where > to get my random port number for the socket I'm using. Keep in mind that Project 2 no longer requires establishing bidirectional communication, so you don't in fact need to set up this sort of rendezvous. Vern From fowler at eecs.berkeley.edu Sun Nov 25 23:36:19 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Sun, 25 Nov 2007 23:36:19 -0800 Subject: [ee122] gathering info with random unused ports (sin_port == 0) In-Reply-To: <200711260716.lAQ7GXe6025098@pork.ICSI.Berkeley.EDU> References: <200711260716.lAQ7GXe6025098@pork.ICSI.Berkeley.EDU> Message-ID: <330471bf0711252336w1b20f5b9xbe0a9370d5173927@mail.gmail.com> On Nov 25, 2007 11:16 PM, wrote: > > From there, though, how do I figure out what port the kernel chose? Did it > > overwrite the value? Is there a function analogous to getpeername() where > > the struct gets filled in with info? > > Yes, see getsockname(). Since with MNL, you need to know the port ahead of time, you might want to use the technique found in TestSend.c (in MNL) and bind the sender's socket to a random port number in advance of doing a sendto. > > I need to advertise the second (incoming on the initiator side) socket to > > the reciever if he is intending to send things back, but I can't find where > > to get my random port number for the socket I'm using. > > Keep in mind that Project 2 no longer requires establishing bidirectional > communication, so you don't in fact need to set up this sort of rendezvous. This is correct in so far as the project specs are asking, because technically, you are able to send ACKs right back to the sockaddr that you got from recvfrom() without having to build another channel of communication. However, if you want to use MNL, you *do* need to share a port number. Note that this is a separate issue! e.g. Sender creates a UDP packet with ports: src 1 dst 500 Sender uses MNL_sendto instead of sendto() MNL re-wraps the packet, and changes UDP ports to: src 90 dst 500 Client reads the sockaddr that it got from recvfrom and sees a sin_port of 90 ! So to send a packet *back* to the Sender (and not MNL), you have to include a reply-to (or source) port in your packet or custom header somehow so that the receiver will be able to rewrite the dst port to 1. Yes? Let me know if that doesn't make sense. Try it out if you get a chance. Lisa From fowler at eecs.berkeley.edu Sun Nov 25 23:37:44 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Sun, 25 Nov 2007 23:37:44 -0800 Subject: [ee122] gathering info with random unused ports (sin_port == 0) In-Reply-To: <330471bf0711252336w1b20f5b9xbe0a9370d5173927@mail.gmail.com> References: <200711260716.lAQ7GXe6025098@pork.ICSI.Berkeley.EDU> <330471bf0711252336w1b20f5b9xbe0a9370d5173927@mail.gmail.com> Message-ID: <330471bf0711252337r5bec0a3cpc1a43f6ddff6d28a@mail.gmail.com> On Nov 25, 2007 11:36 PM, Lisa Fowler wrote: > However, if you want to use MNL, you *do* need to share a port number. Er, by "want to", I mean "when you are ready to incorporate MNL into your app." There is no opting out of using MNL :) -Lisa From ericcheung at berkeley.edu Mon Nov 26 00:32:49 2007 From: ericcheung at berkeley.edu (Eric Cheung) Date: Mon, 26 Nov 2007 00:32:49 -0800 Subject: [ee122] hw4 #5 Message-ID: <474A84B1.5040801@berkeley.edu> Do we have to generate the plots ourselves or can we use another program to generate the plots for us? Thanks - Eric From ericcheung at berkeley.edu Mon Nov 26 00:37:23 2007 From: ericcheung at berkeley.edu (Eric Cheung) Date: Mon, 26 Nov 2007 00:37:23 -0800 Subject: [ee122] project 2 provided files Message-ID: <474A85C3.8000202@berkeley.edu> The project 2 spec says that we will be provided with a skeleton program for our protocol parser/printer, files of various sizes to be transferred between our sender and receiver, and sample MNL configuration files (to be located at http://inst.eecs.berkeley.edu/~ee122/fa07/ projects/p2files/). When will these files be available? Thanks - Eric From fowler at eecs.berkeley.edu Mon Nov 26 00:45:46 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Mon, 26 Nov 2007 00:45:46 -0800 Subject: [ee122] project 2 provided files In-Reply-To: <474A85C3.8000202@berkeley.edu> References: <474A85C3.8000202@berkeley.edu> Message-ID: <330471bf0711260045m8758c4eiec76024c5299087d@mail.gmail.com> The protocol parser will be uploaded shortly, if not already. Please await an announcement from Prof Paxson for its availability. The MNL configs are being standardized and tested right now. For your development and personal testing purposes, sample MNL configs can be found in the MNL tar in the samplecfg directory. The official files should be out within the week. You may use whichever files for the time-being. -Lisa On Nov 26, 2007 12:37 AM, Eric Cheung wrote: > The project 2 spec says that we will be provided with a skeleton program > for our protocol parser/printer, files of various sizes to be > transferred between our sender and receiver, and sample MNL > configuration files (to be located at > http://inst.eecs.berkeley.edu/~ee122/fa07/ > projects/p2files/). When will these files be available? > > Thanks > - Eric > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From jortiz at cs.berkeley.edu Mon Nov 26 07:32:22 2007 From: jortiz at cs.berkeley.edu (Jorge Ortiz) Date: Mon, 26 Nov 2007 07:32:22 -0800 Subject: [ee122] hw4 #5 In-Reply-To: <474A84B1.5040801@berkeley.edu> References: <474A84B1.5040801@berkeley.edu> Message-ID: You shouldn't do it by hand. You should use a program to plot the data. jorge On Nov 26, 2007 12:32 AM, Eric Cheung wrote: > Do we have to generate the plots ourselves or can we use another program > to generate the plots for us? > > Thanks > - Eric > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From vern at cs.berkeley.edu Mon Nov 26 07:56:30 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Mon, 26 Nov 2007 07:56:30 -0800 Subject: [ee122] project 2 provided files In-Reply-To: <474A85C3.8000202@berkeley.edu> (Mon, 26 Nov 2007 00:37:23 PST). Message-ID: <200711261556.lAQFuZJc002672@pork.ICSI.Berkeley.EDU> > http://inst.eecs.berkeley.edu/~ee122/fa07/ > projects/p2files/). When will these files be available? This is held up on getting support on the instructional machines for libpcap, which is the standard Unix packet-capture library. If you want to get a head start on this (or you have access to libpcap on a different machine, or want to install it from www.tcpdump.org), then the files are available in p2files/{packet_parser.c,Makefile}. Vern From a_kilman at berkeley.edu Mon Nov 26 08:21:37 2007 From: a_kilman at berkeley.edu (Anthony Kilman) Date: Mon, 26 Nov 2007 08:21:37 -0800 Subject: [ee122] More byte ordering.. Message-ID: <1196094097.20795.4.camel@zero.cool> Quick question. Suppose we want to convert everything (Jorge I think a previous email you sent suggested to convert "everything" to network byte order to be safe...) in a packet to network byte ordering... and we treat the data as a character array. Also suppose as an example my machine is "blah" endian, and network ordering is the opposite. I already know for an integer: // "blah" endian foobar = 3937 00000000 00000000 00001111 01100001 // network "endian" nFoobar = 1628372992 01100001 00001111 00000000 00000000 But does the same apply to a character array? From dank at eecs.berkeley.edu Mon Nov 26 15:54:57 2007 From: dank at eecs.berkeley.edu (Daniel Killebrew) Date: Mon, 26 Nov 2007 15:54:57 -0800 Subject: [ee122] More byte ordering.. In-Reply-To: <1196094097.20795.4.camel@zero.cool> References: <1196094097.20795.4.camel@zero.cool> Message-ID: <474B5CD1.6090408@eecs.berkeley.edu> Anthony Kilman wrote: > Quick question. Suppose we want to convert everything (Jorge I think a > previous email you sent suggested to convert "everything" to network > byte order to be safe...) in a packet to network byte ordering... and we > treat the data as a character array. Also suppose as an example my > machine is "blah" endian, and network ordering is the opposite. I > already know for an integer: > > // "blah" endian > foobar = 3937 > 00000000 00000000 00001111 01100001 > > // network "endian" > nFoobar = 1628372992 > 01100001 00001111 00000000 00000000 > > But does the same apply to a character array? > You don't need to (nor can you) convert arrays of bytes (and char is 1 byte) to network byte order. As the name indicates, it is network *byte *ordering, not bit ordering. The bit ordering takes care of itself. So if you had a string and wanted to send it over the network, you would just call send(string); This only works for data that is truly an array of bytes. If you were asking if the following would work, it would not: int foo = 3937; send(sock, (char*)&foo, 4, 0); --- the receiver's end-- int bar; recv(sock, (char*)&bar, 4, 0); sprintf("bar is wrong: %d", bar); What I'm saying is: if you are treating data as a character array when it's really an integer, or short, or anything that's longer than 1 byte, you will run into problems if you don't use htonl, htons, etc.. Daniel > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > From ericcheung at berkeley.edu Mon Nov 26 17:02:22 2007 From: ericcheung at berkeley.edu (Eric Cheung) Date: Mon, 26 Nov 2007 17:02:22 -0800 Subject: [ee122] MNL not simulating congestion correctly Message-ID: <474B6C9E.60103@berkeley.edu> We are doubling the RTO after every timeout and reducing the CWND. However, we've run into a problem where MNL (with drop probability .25) keeps dropping packets regardless of how slow we are sending, causing our RTO to keep doubling. This seems to be counter-intuitive to the behavior of an actual congested network, which would drop less packets if a sender reduced its sending speed. Is this a fundamental problem with the way MNL models the network or do we have to account for this somehow? Thanks - Eric From vern at cs.berkeley.edu Mon Nov 26 18:18:50 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Mon, 26 Nov 2007 18:18:50 -0800 Subject: [ee122] More byte ordering.. In-Reply-To: <1196094097.20795.4.camel@zero.cool> (Mon, 26 Nov 2007 08:21:37 PST). Message-ID: <200711270218.lAR2ItHv013891@pork.ICSI.Berkeley.EDU> > Suppose we want to convert everything Just what constitutes "everything" goes to the heart of the question. Byte ordering is about how are multi-byte data types represented in memory. To define a byte order therefore requires specifying how many bytes are in the data type. For strings, there is only one natural order, namely that the starting character is at the lowest position in memory, and the remainder follow in order towards higher positions in memory. (If instead strings grew downward towards lower memory, then array arithmetic wouldn't work on them as a way to extract a particular character.) > previous email you sent suggested to convert "everything" to network > byte order to be safe... He means all data types with fixed, multi-byte representations, as for these there's an ambiguity whether the topmost byte comes first or last. (The issue about array arithmetic doesn't arise because these data types don't directly support extraction of their individual bytes. The bytes are always supposed to be treated as a unit.) Vern From dank at berkeley.edu Tue Nov 27 07:26:44 2007 From: dank at berkeley.edu (Daniel Killebrew) Date: Tue, 27 Nov 2007 07:26:44 -0800 Subject: [ee122] MNL not simulating congestion correctly In-Reply-To: <474B6C9E.60103@berkeley.edu> References: <474B6C9E.60103@berkeley.edu> Message-ID: <474C3734.6010905@berkeley.edu> Eric Cheung wrote: > We are doubling the RTO after every timeout and reducing the CWND. > However, we've run into a problem where MNL (with drop probability .25) > keeps dropping packets regardless of how slow we are sending, causing > our RTO to keep doubling. Well of course, because it's a .25 probability independent of your send rate. > This seems to be counter-intuitive to the > behavior of an actual congested network, which would drop less packets > if a sender reduced its sending speed. Only if that particular sender was responsible for a significant share of the network's congestion. Obviously in reality you are not likely to be that significant (and I mean that in a nice way of course :) ) > Is this a fundamental problem > with the way MNL models the network or do we have to account for this > somehow? > As pointed out above, I wouldn't say that's a problem with MNL. Daniel > Thanks > - Eric > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > From vern at cs.berkeley.edu Tue Nov 27 08:58:45 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Tue, 27 Nov 2007 08:58:45 -0800 Subject: [ee122] Project #1B reference implementations Message-ID: <200711271658.lARGwoID029134@pork.ICSI.Berkeley.EDU> These are now available from http://inst.eecs.berkeley.edu/%7Eee122/fa07/projects/Project1B-ref/client/ http://inst.eecs.berkeley.edu/%7Eee122/fa07/projects/Project1B-ref/server/ - Vern From merry_c at berkeley.edu Tue Nov 27 17:04:03 2007 From: merry_c at berkeley.edu (merry_c at berkeley.edu) Date: Tue, 27 Nov 2007 17:04:03 -0800 (PST) Subject: [ee122] hw4 question1b Message-ID: <33055.128.32.253.148.1196211843.squirrel@calmail.berkeley.edu> For the problem in K&R, Chapter 6, about wireless transmission, does an omniscient controller mean basically that there is no need to account for RTS and CTS? From jortiz at cs.berkeley.edu Tue Nov 27 17:15:14 2007 From: jortiz at cs.berkeley.edu (Jorge Ortiz) Date: Tue, 27 Nov 2007 17:15:14 -0800 Subject: [ee122] hw4 question1b In-Reply-To: <33055.128.32.253.148.1196211843.squirrel@calmail.berkeley.edu> References: <33055.128.32.253.148.1196211843.squirrel@calmail.berkeley.edu> Message-ID: Yes, exactly. The controller tells the nodes when to send. Jorge On Nov 27, 2007 5:04 PM, wrote: > For the problem in K&R, Chapter 6, about wireless transmission, does an > omniscient controller mean basically that there is no need to account for > RTS and CTS? > > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From vern at cs.berkeley.edu Tue Nov 27 21:58:35 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Tue, 27 Nov 2007 21:58:35 -0800 Subject: [ee122] MNL not simulating congestion correctly In-Reply-To: <474C3734.6010905@berkeley.edu> (Tue, 27 Nov 2007 07:26:44 PST). Message-ID: <200711280558.lAS5wev5007623@pork.ICSI.Berkeley.EDU> > > This seems to be counter-intuitive to the > > behavior of an actual congested network, which would drop less packets > > if a sender reduced its sending speed. > Only if that particular sender was responsible for a significant share > of the network's congestion. Exactly. While it can be the case that an individual TCP backing off will by itself lower the drop rate along a path, during situations of high multiplexing, the actions of an individual won't in fact have discernable effect by themselves. (In fact, the notion that the drop rate remains unchanged as a source varies its rate was a basic part of the deriviation of the TCP throughput equation.) Vern From vern at cs.berkeley.edu Wed Nov 28 23:21:04 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Wed, 28 Nov 2007 23:21:04 -0800 Subject: [ee122] packet parsing skeleton (Re: project 2 provided files) In-Reply-To: (Mon, 26 Nov 2007 07:56:30 PST). Message-ID: <200711290721.lAT7L9Wu000467@pork.ICSI.Berkeley.EDU> > > http://inst.eecs.berkeley.edu/~ee122/fa07/ > > projects/p2files/). When will these files be available? > > This is held up on getting support on the instructional machines for > libpcap, which is the standard Unix packet-capture library. This has now been installed on the instructional machines. I've updated p2files/Makefile with the necessary compiler/linker options. There's also now a file p2files/udp.dump which is a trace of a some simple DNS (over UDP) activity. You can exercise the skeleton on this file by invoking "packet_parser udp.dump". Vern From niels at berkeley.edu Wed Nov 28 23:42:55 2007 From: niels at berkeley.edu (niels at berkeley.edu) Date: Wed, 28 Nov 2007 23:42:55 -0800 (PST) Subject: [ee122] Using libraries (glib) Message-ID: <61684.67.169.102.122.1196322175.squirrel@calmail.berkeley.edu> Hello there! Are we allowed to use the glib library? it supplied hash tables, expanding arrays, stuff like that that will make this considerable more manageable. What's the word? Thanks! -Niels From a_kilman at berkeley.edu Thu Nov 29 00:15:58 2007 From: a_kilman at berkeley.edu (Anthony Kilman) Date: Thu, 29 Nov 2007 00:15:58 -0800 Subject: [ee122] Question regarding how to implement a timeout Message-ID: <1196324158.28361.2.camel@zero.cool> Quick question.. how should we implement a timeout? One obvious way would be to use time.h in a while loop.. but just from glancing at my processor usage that seems to eat a lot of cycles.. would select() be a better solution (although its not needed) ? The reason I ask is that I think in Beej's guide somewhere it mentioned sending the process to sleep until some activity occurred. Thanks in advance. Anthony From fowler at eecs.berkeley.edu Thu Nov 29 00:21:12 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Thu, 29 Nov 2007 00:21:12 -0800 Subject: [ee122] Question regarding how to implement a timeout In-Reply-To: <1196324158.28361.2.camel@zero.cool> References: <1196324158.28361.2.camel@zero.cool> Message-ID: <330471bf0711290021n1a5d8f0aqbd878460d06316ec@mail.gmail.com> You can use select() in this case. You may find need for a timer in non-select-based cases, and if so, check out time(), clock(), and gettimeofday(). There's also polling (via poll()), but I think select will do you just fine. -Lisa On Nov 29, 2007 12:15 AM, Anthony Kilman wrote: > Quick question.. how should we implement a timeout? One obvious way > would be to use time.h in a while loop.. but just from glancing at my > processor usage that seems to eat a lot of cycles.. would select() be a > better solution (although its not needed) ? The reason I ask is that I > think in Beej's guide somewhere it mentioned sending the process to > sleep until some activity occurred. > > Thanks in advance. > > Anthony > > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From dank at eecs.berkeley.edu Thu Nov 29 01:45:04 2007 From: dank at eecs.berkeley.edu (Daniel Killebrew) Date: Thu, 29 Nov 2007 01:45:04 -0800 Subject: [ee122] Using libraries (glib) In-Reply-To: <61684.67.169.102.122.1196322175.squirrel@calmail.berkeley.edu> References: <61684.67.169.102.122.1196322175.squirrel@calmail.berkeley.edu> Message-ID: <474E8A20.8050805@eecs.berkeley.edu> niels at berkeley.edu wrote: > Hello there! > > Are we allowed to use the glib library? it supplied hash tables, Standard Template Library (STL) has these, see map<> > expanding > arrays, and STL has these, see vector<> of course you have to use C++ to leverage STL. Daniel > stuff like that that will make this considerable more manageable. > What's the word? > > Thanks! > > -Niels > > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > From fowler at eecs.berkeley.edu Thu Nov 29 08:57:29 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Thu, 29 Nov 2007 08:57:29 -0800 Subject: [ee122] Using libraries (glib) In-Reply-To: <474E8A20.8050805@eecs.berkeley.edu> References: <61684.67.169.102.122.1196322175.squirrel@calmail.berkeley.edu> <474E8A20.8050805@eecs.berkeley.edu> Message-ID: <330471bf0711290857p2f8a8de3oad0048998182f5f4@mail.gmail.com> You may use whichever non-networking packages that you may find helpful. If you're used to glib, then go for it. -Lisa On Nov 29, 2007 1:45 AM, Daniel Killebrew wrote: > > > niels at berkeley.edu wrote: > > Hello there! > > > > Are we allowed to use the glib library? it supplied hash tables, > Standard Template Library (STL) has these, see map<> > > expanding > > arrays, > and STL has these, see vector<> > of course you have to use C++ to leverage STL. > > Daniel > > > stuff like that that will make this considerable more manageable. > > What's the word? > > > > Thanks! > > > > -Niels > > > > _______________________________________________ > > ee122 mailing list > > ee122 at mailman.ICSI.Berkeley.EDU > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > > > > > _______________________________________________ > ee122 mailing list > ee122 at mailman.ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122 > From merry_c at berkeley.edu Thu Nov 29 18:24:34 2007 From: merry_c at berkeley.edu (Merry Choi) Date: Thu, 29 Nov 2007 18:24:34 -0800 Subject: [ee122] MNL Daemon In-Reply-To: <330471bf0711290857p2f8a8de3oad0048998182f5f4@mail.gmail.com> Message-ID: What should the LD_LIBRARY_PATH= if you are running MNLDaemon under Cygwin on Windows? From vern at cs.berkeley.edu Thu Nov 29 23:22:49 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Thu, 29 Nov 2007 23:22:49 -0800 Subject: [ee122] update to Project 2 Message-ID: <200711300722.lAU7Mssu026888@pork.ICSI.Berkeley.EDU> We've updated the Project 2 writeup with a fairly minor change, namely a new version of MNL that supports controlling the random-number generator's seed (to allow reproducible behavior when debugging). See the Announcements page for links to it and MNL 0.1b. I've appended diffs between this version of the writeup and the previous one. Vern Index: Project2.tex =================================================================== --- Project2.tex (revision 255) +++ Project2.tex (revision 265) @@ -34,7 +34,7 @@ }{\end{enumerate}} \title{ \Large EE122: Introduction to Computer Networks --- Fall 2007 \\[0.2in] -\bf { Project 2: Design a Reliable Transfer Protocol\footnote{Version 3: Tue Nov 20 -- Porting Project \#1 client/server is now optional for extra credit. This changes the specifics of what programs you turn in for the main credit (they are now simple file transfer programs.) Version 2: Fri Nov 2 -- Clarified abstracted system calls.} }\\[0.15in] +\bf { Project 2: Design a Reliable Transfer Protocol\footnote{Version 4: Mon Nov 26 -- Updated MNL to version 0.1b, which now provide for either non-deterministic or deterministic random numbers. Version 3: Tue Nov 20 -- Porting Project \#1 client/server is now optional for extra credit. This changes the specifics of what programs you turn in for the main credit (they are now simple file transfer programs.) Version 2: Fri Nov 2 -- Clarified abstracted system calls.} }\\[0.15in] \normalsize{ Phase 1 --- Due Tue Nov 13, 2007 11PM\\ Phase 2 --- Due Sat Dec ~8, 2007 11PM }\\[0.1in] } @@ -308,6 +308,10 @@ which is provided by the kernel via {\tt sys/socket.h} system calls. Each layer has its own notion of the above system calls. Take care to know which you are using! + + Note that the MNLEmulator can only affect outgoing + packets, so you will have to support MNL on both your + sending and receiving applications. \item For the extra credit, you do not have to worry about ensuring that your Project~1 @@ -544,13 +548,16 @@ for traces from the sender's perspective and the receiver's perspective, respectively, where {\tt x} indicates the number of the corresponding config file and transfer file.\footnote{ - {\it E.g.,} you will pair {\tt mnl\_conf\_3.txt} with - {\tt file3.txt} by running {\tt MNLDaemon mnl\_conf\_3.txt} - and then have your sender transfer {\tt file3.txt} to your receiver. + {\it E.g.,} you will use {\tt mnl\_conf\_3s.txt} (sender) and + {\tt mnl\_conf\_3r.txt} (receiver) with + {\tt file3.txt} by running {\tt MNLDaemon mnl\_conf\_3s.txt} + and then have your sender transfer {\tt file3.txt} to your receiver, + which is running {\tt MNLDaemon mnl\_conf\_3r.txt}. You will capture the packets exchanged using either {\tt tshark} or - {\tt tcpdump}. You will then parse the results, and populate - and name the sample files {\tt cc\_send\_3.csv} and - {\tt cc\_recv\_3.csv} . + {\tt tcpdump} running on the same system as your sender, and then + your client as appropriate. You will then parse the results, and populate + and name the sample files {\tt cc\_send\_3.csv} (traced on the + sender's host) and {\tt cc\_recv\_3.csv} (traced on the receiver's host). } You will find the particular MNL configuration files and the files that you must transfer between the sender and receiver at @@ -591,9 +598,9 @@ \subsection{Downloading and Unpacking MNL} -Download the latest version of the MNL simulator (MNL version 0.1a) from +Download the latest version of the MNL simulator (MNL version 0.1b) from the course webpage at\\ -\url{http://inst.eecs.berkeley.edu/~ee122/fa07/projects/MNL_0_1a.tar.gz}\\ +\url{http://inst.eecs.berkeley.edu/~ee122/fa07/projects/MNL_0_1b.tar.gz}\\ Untar/Unzip it into the directory containing your source code. \subsection{Example Programs} @@ -729,7 +736,14 @@ \end{packed_enum} -Some sample configuration files are given in the {\tt MyNetworkLayer/samplecfg} +The optional fourth line can specify a value to be used as a deterministic +seed to the random number generator used by MNLDaemon. If you use +specify a number here, you will be able to repeat the same probabilistic +drops every time you use that config file. If you do not specify a +number, the drops will be random and non-deterministic between +each execution. + +Some sample configuration files are given in the {\tt samplecfg} subdirectory. \subsection{Non-Solaris Platforms} From a_kilman at berkeley.edu Fri Nov 30 01:25:19 2007 From: a_kilman at berkeley.edu (Anthony Kilman) Date: Fri, 30 Nov 2007 01:25:19 -0800 Subject: [ee122] Question regarding handshake robustness Message-ID: <1196414719.12708.5.camel@zero.cool> Hello. I'm testing the robustness of my handshake by throwing a ton of random data at my sender. Basically I have a malicious "receiver" that catches the SYN, extracts the info needed to identify the sender, and just bombards the sender with random packets. It ends up crashing my sender. But it works in other cases (included a FEW [as supposed to 1000+] random UDP packets in the handshake progress). Should we handle this in our code, or is this a bit off topic in regards to the objectives of the project. I guess it could be more of a security issue more than anything. Out of curiosity, why would it crash? Is there an associated buffer for UDP from the OS that's getting overwhelmed? Or am I missing something? Thanks. From vern at cs.berkeley.edu Fri Nov 30 08:11:17 2007 From: vern at cs.berkeley.edu (vern at cs.berkeley.edu) Date: Fri, 30 Nov 2007 08:11:17 -0800 Subject: [ee122] Question regarding handshake robustness In-Reply-To: <1196414719.12708.5.camel@zero.cool> (Fri, 30 Nov 2007 01:25:19 PST). Message-ID: <200711301611.lAUGBMRH004720@pork.ICSI.Berkeley.EDU> > Should we handle this in our code, or is this a bit off topic > in regards to the objectives of the project. No need to handle this case. > Out of curiosity, why would it crash? Is there an associated buffer for > UDP from the OS that's getting overwhelmed? Or am I missing something? It's almost certainly not a kernel problem. The way to understand this further would be to run using the debugger and see exactly where the process is crashing. Vern From fowler at eecs.berkeley.edu Fri Nov 30 20:51:21 2007 From: fowler at eecs.berkeley.edu (Lisa Fowler) Date: Fri, 30 Nov 2007 20:51:21 -0800 Subject: [ee122] Reminder: Test on c199 Message-ID: <330471bf0711302051m1bdcaf86kee336bbb8c93dfd5@mail.gmail.com> Don't forget to periodically test your program on c199 to help minimize the last minute panic of making sure your program is compatible with c199...! You will have to recompile MNL, particularly the MNLDaemon. You will have to do so in the src directory and by using gmake. Let me know if you have problems. -Lisa