[ee122] hmwk problem Number 2.16

Nescio Nomen nescionomen at gmail.com
Thu Sep 20 18:08:31 PDT 2007


The definition I'm using is on P. 242-243.  I'm not sure there is a
conflict.  You're interpreting "data" in your sentence to mean "payload,"
I'm not sure this is the case.  Assuming the book does not contradict
itself, looking at the definition on P.242-243, I would guess that "data" in
your sentence means "the stuff in the link layer frame [including the
header]."  But it's not very precise language so maybe I'm wrong and the
book does contradict itself.

On 9/20/07, Jonathan D. Ellithorpe <jde at berkeley.edu> wrote:
>
> Ah very interesting. That is why you and I are saying different things.
>
> On page 339 of the textbook it says:
>
> "The maximum amount of data that a link layer frame can carry is called
> the maximum transmission unit (MTU)."
>
> Which conflicts directly with:
>
> "MTU is the length of the largest link-layer frame that can be sent by
> the local sending host"
>
>
>
> Nescio Nomen wrote:
> > Is it defined for packets or for frames?  I'm finding conflicting
> > definitions on google.  The book says that the MTU is the "length of
> > the largest link-layer frame that can be sent by the local sending
> > host"-- hence my confusion since we're not provided any link layer
> > header info.  But, if I understand what you've said earlier, we're to
> > assume it's strictly going to only have IP header anyway.
> >
> > On 9/20/07, *Jorge Ortiz* <jortiz at cs.berkeley.edu
> > <mailto:jortiz at cs.berkeley.edu>> wrote:
> >
> >     The MTU is the largest sized packet that can be passed.  This
> includes
> >     header information.
> >
> >
> >     On 9/20/07, Nescio Nomen <nescionomen at gmail.com
> >     <mailto:nescionomen at gmail.com>> wrote:
> >     > Oh wait, I think I understand-- you're saying that MTU does not
> >     include the
> >     > link header size?
> >     >
> >     >
> >     > On 9/20/07, Nescio Nomen < nescionomen at gmail.com
> >     <mailto:nescionomen at gmail.com>> wrote:
> >     > > I'm not sure I understand.  (in a real life problem) why
> >     wouldn't we need
> >     > to know the size of the frame header just because we are given
> >     the MTU?
> >     > Wouldn't we try to find the amount of 'real data' that could fit
> >     by doing
> >     > something along the lines of MTU - frame header size - IP header
> >     size -
> >     > Layer 4 header size?
> >     > >
> >     > >
> >     > >
> >     > > On 9/20/07, Jonathan D. Ellithorpe < jde at berkeley.edu
> >     <mailto:jde at berkeley.edu>> wrote:
> >     > > > I think the MTU is actually defined as being the maximum
> >     amount of data
> >     > > > that a link layer frame can encapsulate. Thus, we don't need
> >     to consider
> >     > > > the size of the frame, since we're just given the MTU of the
> >     link-layer.
> >     > > >
> >     > > >
> >     > > > Jorge Ortiz wrote:
> >     > > > > On 9/20/07, Nescio Nomen <nescionomen at gmail.com
> >     <mailto:nescionomen at gmail.com>> wrote:
> >     > > > >
> >     > > > >> For hmwk Problem #2, P16, do we know if the datagram will
> >     have a TCP
> >     > header
> >     > > > >> inside?  (Is it necessarily the case that a datagram always
> >     > encapsulated a
> >     > > > >> TCP header?)
> >     > > > >>
> >     > > > >
> >     > > > > If it's specified as only being a plane datagram (as it is
> >     in the
> >     > > > > problem), we only need to include the IP header.
> >     > > > >
> >     > > > >
> >     > > > >> Also, when we are transmitting into the link, how big is
> the
> >     > > > >> frame header?
> >     > > > >>
> >     > > > >
> >     > > > > Treat the packet as having only an IP header and the data
> >     you wish to
> >     > send.
> >     > > > >
> >     > > > >
> >     > > > >> We haven't really talked about this layer yet.  Does the
> >     size
> >     > > > >> of the frame header depend on the technology, i.e. optical?
> >     > > > >>
> >     > > > >
> >     > > > > It may, yes.  Different mediums may have different header
> >     definitions.
> >     > > > >
> >     > > > > jorge
> >     > > > >
> >     > > > >
> >     > > > >> _______________________________________________
> >     > > > >> ee122 mailing list
> >     > > > >> ee122 at mailman.ICSI.Berkeley.EDU
> >     <mailto:ee122 at mailman.ICSI.Berkeley.EDU>
> >     > > > >>
> >     > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
> >     <http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122>
> >     > > > >>
> >     > > > >>
> >     > > > >>
> >     > > > > _______________________________________________
> >     > > > > ee122 mailing list
> >     > > > > ee122 at mailman.ICSI.Berkeley.EDU
> >     <mailto:ee122 at mailman.ICSI.Berkeley.EDU>
> >     > > > >
> >     > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
> >     <http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122>
> >     > > > >
> >     > > > >
> >     > > >
> >     > > > _______________________________________________
> >     > > > ee122 mailing list
> >     > > > ee122 at mailman.ICSI.Berkeley.EDU
> >     <mailto:ee122 at mailman.ICSI.Berkeley.EDU>
> >     > > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
> >     > > >
> >     > >
> >     > >
> >     >
> >     >
> >     > _______________________________________________
> >     > ee122 mailing list
> >     > ee122 at mailman.ICSI.Berkeley.EDU
> >     <mailto: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20070920/85321580/attachment-0001.html 


More information about the ee122 mailing list