|
Home > Archive > alt.certification.cisco > August 2003 > Who resend ?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| YannickC 2003-08-26, 4:25 am |
| You have a host 1 and a host 2 on two different Ethernet segments.The
hosts are separated by a repeater,a bridge, 2 bridges connected by a
serial line, and 2 routers. In each scenario who retransmits in the
event of an error ?
I can answer that the hub in not intelligent, so this equipement can
detect an error (collisio, jabber, runt, giant...) but will not
retransmit. Do bridges retransmit ? In my opinion, they drop the frame
as hub. I would say that routers do the same, so in all cases, host
will retransmit, am I wrong ?
| |
| André Franke 2003-08-26, 4:25 am |
| yannick@mail.opt.pf (YannickC) wrote:
>You have a host 1 and a host 2 on two different Ethernet segments.The
>hosts are separated by a repeater,a bridge, 2 bridges connected by a
>serial line, and 2 routers. In each scenario who retransmits in the
>event of an error ?
>
>I can answer that the hub in not intelligent, so this equipement can
>detect an error (collisio, jabber, runt, giant...) but will not
>retransmit. Do bridges retransmit ? In my opinion, they drop the frame
>as hub. I would say that routers do the same, so in all cases, host
>will retransmit, am I wrong ?
In general you are right.
There are routers which provide layer 4 functionality but that is not
a general router function.
Retransmission is a function of TCP which resides at layer 4 the
transport layer of the OSI model.
regards
André
| |
| YannickC 2003-08-26, 9:24 pm |
| André Franke <dump.it@digital-filestore.de> wrote in message news:< 873mkvs1258il9grdndprmcp607v7q
60e9@4ax.com>...
> yannick@mail.opt.pf (YannickC) wrote:
>
> >You have a host 1 and a host 2 on two different Ethernet segments.The
> >hosts are separated by a repeater,a bridge, 2 bridges connected by a
> >serial line, and 2 routers. In each scenario who retransmits in the
> >event of an error ?
> >
> >I can answer that the hub in not intelligent, so this equipement can
> >detect an error (collisio, jabber, runt, giant...) but will not
> >retransmit. Do bridges retransmit ? In my opinion, they drop the frame
> >as hub. I would say that routers do the same, so in all cases, host
> >will retransmit, am I wrong ?
>
> In general you are right.
> There are routers which provide layer 4 functionality but that is not
> a general router function.
> Retransmission is a function of TCP which resides at layer 4 the
> transport layer of the OSI model.
>
> regards
> André
I would modify my answer and say that is the responsability of the
sender to resend a bad frame to the receiver to inform the sender if
the layer 2 supports error recovery and dectection.
For ethernet (connectionless)the sender detect its own bad frame and
resends, the receiver do nothing
For serial link between router, routers detect provide error detection
and recovery (PPP, HDLC, ATM, connected protocols) the sending router
resends the frame not the host as it dectects it (time out, bad
sequence), the receiveing router informs the sending router in case of
error (time out, bad sequencing, bad crc, fcs, hec...)
Yannick.
CCNP
CCIE R/S canditate
| |
| Hansang Bae 2003-08-27, 1:26 am |
| In article <f4d6f831.0308261643.611e618b@posting.google.com>,
yannick@mail.opt.pf says...
> I would modify my answer and say that is the responsability of the
> sender to resend a bad frame to the receiver to inform the sender if
> the layer 2 supports error recovery and dectection.
> For ethernet (connectionless)the sender detect its own bad frame and
> resends, the receiver do nothing
The NIC does not resend anything. If it detects a bad CRC on
*receiving* the frame, it'll throw it away. But when you send, it
doesn't do any error checking a la ACKs or NACKs.
> For serial link between router, routers detect provide error detection
> and recovery (PPP, HDLC, ATM, connected protocols) the sending router
> resends the frame not the host as it dectects it (time out, bad
> sequence), the receiveing router informs the sending router in case of
> error (time out, bad sequencing, bad crc, fcs, hec...)
The router cannot resend the packet. Once a packet leaves the router,
that's it. The router doesn't hold X number of packets just in case it
needs to resend the packet. It's up to the end stations to retransmit.
--
hsb
"Somehow I imagined this experience would be more rewarding" Calvin
*************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
******************************
******************************
********
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
******************************
******************************
********
| |
| André Franke 2003-08-27, 6:25 am |
| Hansang Bae <uonr@alp.ee.pbz> wrote:
>In article <f4d6f831.0308261643.611e618b@posting.google.com>,
>yannick@mail.opt.pf says...
>> I would modify my answer and say that is the responsability of the
>> sender to resend a bad frame to the receiver to inform the sender if
>> the layer 2 supports error recovery and dectection.
>> For ethernet (connectionless)the sender detect its own bad frame and
>> resends, the receiver do nothing
>
>The NIC does not resend anything. If it detects a bad CRC on
>*receiving* the frame, it'll throw it away. But when you send, it
>doesn't do any error checking a la ACKs or NACKs.
That's correct. Within the according RFCs the term "silently discard"
is used. Since each layer participating in true encapsulation is
unable to calculate the header and trailer of the next higher layer,
it can only see if the header and trailer of its corresponding
layer(peer) is ok. Just how you would check a parcel for damaged
packing and if the weight is the same as written on it(CRC).You can't
really tell if the china vase inside doesn't have a crack, while you
are not allowed to open the parcel.
And since there is not such thing like an ID number on a bit, a frame
or a packet, neither of physical, datalink and network layer could
tell the sender which of the recieved PDUs was damaged.
The first layer numbering it's PDUs is the transport layer using
reliable mechanisms like those of TCP or SPX sequencing.
>> For serial link between router, routers detect provide error detection
>> and recovery (PPP, HDLC, ATM, connected protocols) the sending router
>> resends the frame not the host as it dectects it (time out, bad
>> sequence), the receiveing router informs the sending router in case of
>> error (time out, bad sequencing, bad crc, fcs, hec...)
>
>
>The router cannot resend the packet. Once a packet leaves the router,
>that's it. The router doesn't hold X number of packets just in case it
>needs to resend the packet. It's up to the end stations to retransmit.
Again this is correct. Yannic, what you are thinking of is a proxy.
But in terms of the OSI reference model a proxy is nothing else than a
host. It stores information to shorten the distance between sender and
reciever.
Routing facilities may have a proxy implemented but then they are no
longer only routers, but rather more proxy hosts providing routing
functionality. The router itself does only forwarding of the "Missing
In Action" notifications and the recovery-resends of the upper layers.
Those "Missing In Action" events are caused by lower layers silently
discarding damaged PDUs.
regards
André
| |
| John Agosta 2003-08-27, 3:24 pm |
| I find this discussion very interesting.
Some thoughts are inserted, in-line....
"André Franke" <dump.it@digital-filestore.de> wrote in message
news:cluokvk7taiiviic5a6rml23j
tqinnr0cv@4ax.com...
> Hansang Bae <uonr@alp.ee.pbz> wrote:
>
> >In article <f4d6f831.0308261643.611e618b@posting.google.com>,
> >yannick@mail.opt.pf says...
> >> I would modify my answer and say that is the responsability of the
> >> sender to resend a bad frame to the receiver to inform the sender if
> >> the layer 2 supports error recovery and dectection.
> >> For ethernet (connectionless)the sender detect its own bad frame and
> >> resends, the receiver do nothing
> >
> >The NIC does not resend anything. If it detects a bad CRC on
> >*receiving* the frame, it'll throw it away. But when you send, it
> >doesn't do any error checking a la ACKs or NACKs.
>
> That's correct. Within the according RFCs the term "silently discard"
> is used. Since each layer participating in true encapsulation is
> unable to calculate the header and trailer of the next higher layer,
> it can only see if the header and trailer of its corresponding
> layer(peer) is ok. Just how you would check a parcel for damaged
> packing and if the weight is the same as written on it(CRC).You can't
> really tell if the china vase inside doesn't have a crack, while you
> are not allowed to open the parcel.
> And since there is not such thing like an ID number on a bit, a frame
> or a packet, neither of physical, datalink and network layer could
> tell the sender which of the recieved PDUs was damaged.
> The first layer numbering it's PDUs is the transport layer using
> reliable mechanisms like those of TCP or SPX sequencing.
>
The first layer that "numbers" its PDUs is not always layer 4.
For example, LLC Type 2 will includes NS and NR sequencing, even when
operating on an Ethernet medium.
LLC type 2 isn't used for IP transmission, but it "does" exist for other
protocols.
Also, IP itself at layer 3 identifies each datagram with a number. Although
the datagram ID is not used for
error correction purposes - it is used for re-assembling fragmented
datagrams. So within the context of
(bit) error detection and correction, IP does not use sequence numbers for
that purpose. However, IP
does indeed number its PDUs for other purposes.
[colo
r=darkred]
> >> For serial link between router, routers detect provide error detection
> >> and recovery (PPP, HDLC, ATM, connected protocols) the sending router
> >> resends the frame not the host as it dectects it (time out, bad
> >> sequence), the receiveing router informs the sending router in case of
> >> error (time out, bad sequencing, bad crc, fcs, hec...)
> >
> >
> >The router cannot resend the packet. Once a packet leaves the router,
> >that's it. The router doesn't hold X number of packets just in case it
> >needs to resend the packet. It's up to the end stations to retransmit.
>
> Again this is correct. Yannic, what you are thinking of is a proxy.
> But in terms of the OSI reference model a proxy is nothing else than a
> host. It stores information to shorten the distance between sender and
> reciever.
> Routing facilities may have a proxy implemented but then they are no
> longer only routers, but rather more proxy hosts providing routing
> functionality. The router itself does only forwarding of the "Missing
> In Action" notifications and the recovery-resends of the upper layers.
> Those "Missing In Action" events are caused by lower layers silently
> discarding damaged PDUs.
>
> regards
> André[/color]
Regarding who can 're-send,' the CSMA/CD standard for 1/2 dux ethernet does
specify how
the MAC sublayer can detect a collision, and attempt to re-access the medium
to retransmit the frame.
So, an ethernet NIC 'can' retransmit frames. It does not retransmit due to
detecting corrupted frames / CRC events,
but will retransmit in the event of contention for media access. Even a
switch port operating in 1/2 duplex mode
will retransmit when detecting collisions when attempting to access the
medium.
So the question of "who retransmits?" is ........"it depends."
One cannot answer the question accurately unless the 'scenario-specific'
context is being taken into consideration,
IE - what protocols are being used, and what event "caused" the failure of
the first transmission attempt.
-ja
| |
| YannickC 2003-08-27, 4:25 pm |
| André Franke <dump.it@digital-filestore.de> wrote in message news:< cluokvk7taiiviic5a6rml23jtqinn
r0cv@4ax.com>...
> Hansang Bae <uonr@alp.ee.pbz> wrote:
>
> >In article <f4d6f831.0308261643.611e618b@posting.google.com>,
> >yannick@mail.opt.pf says...
> >> I would modify my answer and say that is the responsability of the
> >> sender to resend a bad frame to the receiver to inform the sender if
> >> the layer 2 supports error recovery and dectection.
> >> For ethernet (connectionless)the sender detect its own bad frame and
> >> resends, the receiver do nothing
> >
> >The NIC does not resend anything. If it detects a bad CRC on
> >*receiving* the frame, it'll throw it away. But when you send, it
> >doesn't do any error checking a la ACKs or NACKs.
>
> That's correct. Within the according RFCs the term "silently discard"
> is used. Since each layer participating in true encapsulation is
> unable to calculate the header and trailer of the next higher layer,
> it can only see if the header and trailer of its corresponding
> layer(peer) is ok. Just how you would check a parcel for damaged
> packing and if the weight is the same as written on it(CRC).You can't
> really tell if the china vase inside doesn't have a crack, while you
> are not allowed to open the parcel.
> And since there is not such thing like an ID number on a bit, a frame
> or a packet, neither of physical, datalink and network layer could
> tell the sender which of the recieved PDUs was damaged.
> The first layer numbering it's PDUs is the transport layer using
> reliable mechanisms like those of TCP or SPX sequencing.
>
Ethernet resends in case of error (collision detection) that why it is
named CSMA/CD, it tries up to 16 times, truncated binary exponential
back-off algorithm.
André could you give me the rfc number please.
[colo
r=darkred]
> >> For serial link between router, routers detect provide error detection
> >> and recovery (PPP, HDLC, ATM, connected protocols) the sending router
> >> resends the frame not the host as it dectects it (time out, bad
> >> sequence), the receiveing router informs the sending router in case of
> >> error (time out, bad sequencing, bad crc, fcs, hec...)
> >
> >
> >The router cannot resend the packet. Once a packet leaves the router,
> >that's it. The router doesn't hold X number of packets just in case it
> >needs to resend the packet. It's up to the end stations to retransmit.
>
> Again this is correct. Yannic, what you are thinking of is a proxy.
> But in terms of the OSI reference model a proxy is nothing else than a
> host. It stores information to shorten the distance between sender and
> reciever.
> Routing facilities may have a proxy implemented but then they are no
> longer only routers, but rather more proxy hosts providing routing
> functionality. The router itself does only forwarding of the "Missing
> In Action" notifications and the recovery-resends of the upper layers.
> Those "Missing In Action" events are caused by lower layers silently
> discarding damaged PDUs.
>
> regards
> André[/color]
It depends on the protocol used, PPP detects errors (LQM) but does not
resend.
In the case of HDLC, this "High Level Data Link Connection" protocol
manages errors and resends. there are sequence and acknowledgement
numbers. X25 uses it.
| |
|
|
"YannickC" <yannick@mail.opt.pf> wrote in message
news:f4d6f831.0308271206.61dd337d@posting.google.com...
> André Franke <dump.it@digital-filestore.de> wrote in message
news:< cluokvk7taiiviic5a6rml23jtqinn
r0cv@4ax.com>...
> > Hansang Bae <uonr@alp.ee.pbz> wrote:
> >
> > >In article <f4d6f831.0308261643.611e618b@posting.google.com>,
> > >yannick@mail.opt.pf says...
> > >> I would modify my answer and say that is the responsability of the
> > >> sender to resend a bad frame to the receiver to inform the sender if
> > >> the layer 2 supports error recovery and dectection.
> > >> For ethernet (connectionless)the sender detect its own bad frame and
> > >> resends, the receiver do nothing
> > >
> > >The NIC does not resend anything. If it detects a bad CRC on
> > >*receiving* the frame, it'll throw it away. But when you send, it
> > >doesn't do any error checking a la ACKs or NACKs.
> >
> > That's correct. Within the according RFCs the term "silently discard"
> > is used. Since each layer participating in true encapsulation is
> > unable to calculate the header and trailer of the next higher layer,
> > it can only see if the header and trailer of its corresponding
> > layer(peer) is ok. Just how you would check a parcel for damaged
> > packing and if the weight is the same as written on it(CRC).You can't
> > really tell if the china vase inside doesn't have a crack, while you
> > are not allowed to open the parcel.
> > And since there is not such thing like an ID number on a bit, a frame
> > or a packet, neither of physical, datalink and network layer could
> > tell the sender which of the recieved PDUs was damaged.
> > The first layer numbering it's PDUs is the transport layer using
> > reliable mechanisms like those of TCP or SPX sequencing.
> >
> Ethernet resends in case of error (collision detection) that why it is
> named CSMA/CD, it tries up to 16 times, truncated binary exponential
> back-off algorithm.
> André could you give me the rfc number please.
>
> > >> For serial link between router, routers detect provide error
detection
> > >> and recovery (PPP, HDLC, ATM, connected protocols) the sending router
> > >> resends the frame not the host as it dectects it (time out, bad
> > >> sequence), the receiveing router informs the sending router in case
of[co
lor=darkred]
> > >> error (time out, bad sequencing, bad crc, fcs, hec...)
> > >
> > >
> > >The router cannot resend the packet. Once a packet leaves the router,
> > >that's it. The router doesn't hold X number of packets just in case it
> > >needs to resend the packet. It's up to the end stations to retransmit.
> >
> > Again this is correct. Yannic, what you are thinking of is a proxy.
> > But in terms of the OSI reference model a proxy is nothing else than a
> > host. It stores information to shorten the distance between sender and
> > reciever.
> > Routing facilities may have a proxy implemented but then they are no
> > longer only routers, but rather more proxy hosts providing routing
> > functionality. The router itself does only forwarding of the "Missing
> > In Action" notifications and the recovery-resends of the upper layers.
> > Those "Missing In Action" events are caused by lower layers silently
> > discarding damaged PDUs.
> >
> > regards
> > André
>
> It depends on the protocol used, PPP detects errors (LQM) but does not
> resend.
> In the case of HDLC, this "High Level Data Link Connection" protocol
> manages errors and resends. there are sequence and acknowledgement
> numbers. X25 uses it.[/color]
Just to through some more confusion into the mix..
If you have Host A that is connected to Switch A, and Host B that is
connected to Switch B. Switch A and B are cross connected to each other and
configured for store and forward. If Host A sent a packet to Host B at the
exact same time that Host B sent a packet to Host A. The packets would be
recieved by their corisonding switches at the same time. The switches would
then try to transmit the packet over the cross connect at the same time. A
collision would be detected. Now as the switches are store and forware,
would they do their own retransmision because the cross connect is in it's
own collision domain?
| |
| Hansang Bae 2003-08-27, 8:24 pm |
| In article <ssmdnUaEypseYtGiU-KYuA@wideopenwest.com>,
j_agosta@wideopenwest.kom says...
> The first layer that "numbers" its PDUs is not always layer 4.
> For example, LLC Type 2 will includes NS and NR sequencing, even when
> operating on an Ethernet medium.
> LLC type 2 isn't used for IP transmission, but it "does" exist for other
> protocols.
But no one uses it so I left it out. I had to learn LLC/2 because of
the stupid CNX cert!  There was a web page that explained it in
painful detail!
> Regarding who can 're-send,' the CSMA/CD standard for 1/2 dux ethernet does
> specify how
> the MAC sublayer can detect a collision, and attempt to re-access the medium
> to retransmit the frame.
> So, an ethernet NIC 'can' retransmit frames. It does not retransmit due to
> detecting corrupted frames / CRC events,
> but will retransmit in the event of contention for media access. Even a
> switch port operating in 1/2 duplex mode
> will retransmit when detecting collisions when attempting to access the
> medium.
But the problem is that "retransmision" in this cconversation is
actually resending the entire package. If a collision is detected, the
NIC stops transmitting the actual frame. Since it never finished
sending it in the first, place, you can't really say it's
"re"transmitting. But the original sender wasn't going into this level
of detail so I guess it's an academic exercise only!
--
hsb
"Somehow I imagined this experience would be more rewarding" Calvin
*************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
******************************
******************************
********
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
******************************
******************************
********
| |
| Hansang Bae 2003-08-27, 8:24 pm |
| In article <f4d6f831.0308271206.61dd337d@posting.google.com>,
yannick@mail.opt.pf says...
> Ethernet resends in case of error (collision detection) that why it is
> named CSMA/CD, it tries up to 16 times, truncated binary exponential
> back-off algorithm.
But a collision isn't an error condition. It's just how it works.
--
hsb
"Somehow I imagined this experience would be more rewarding" Calvin
*************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
******************************
******************************
********
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
******************************
******************************
********
| |
| John Agosta 2003-08-27, 10:24 pm |
|
"Hansang Bae" <uonr@alp.ee.pbz> wrote in message
news:MPG.19b70c9a6e444cfc989a88@news-server.nyc.rr.com...
> In article <ssmdnUaEypseYtGiU-KYuA@wideopenwest.com>,
> j_agosta@wideopenwest.kom says...
>
> > The first layer that "numbers" its PDUs is not always layer 4.
> > For example, LLC Type 2 will includes NS and NR sequencing, even when
> > operating on an Ethernet medium.
> > LLC type 2 isn't used for IP transmission, but it "does" exist for other
> > protocols.
>
> But no one uses it so I left it out. I had to learn LLC/2 because of
> the stupid CNX cert! There was a web page that explained it in
> painful detail!
>
>
> > Regarding who can 're-send,' the CSMA/CD standard for 1/2 dux ethernet
does
> > specify how
> > the MAC sublayer can detect a collision, and attempt to re-access the
medium
> > to retransmit the frame.
> > So, an ethernet NIC 'can' retransmit frames. It does not retransmit due
to
> > detecting corrupted frames / CRC events,
> > but will retransmit in the event of contention for media access. Even a
> > switch port operating in 1/2 duplex mode
> > will retransmit when detecting collisions when attempting to access the
> > medium.
>
> But the problem is that "retransmision" in this cconversation is
> actually resending the entire package. If a collision is detected, the
> NIC stops transmitting the actual frame. Since it never finished
> sending it in the first, place, you can't really say it's
> "re"transmitting. But the original sender wasn't going into this level
> of detail so I guess it's an academic exercise only!
>
>
>
I guess we are picking nits here, but the IEEE document uses the term
"retransmission" with
respect to recovering from collisions, even though the initial transmission
attempt was "terminated"
before completion.....But like I said, this is just picking nits.
My main point was to state that it is not always Layer 4 that retransmits,
and not to disagree with your
(as usual) valid observations......
So, HSB, when are you gonna email me with your info so I can send you that
CD?
-ja
| |
| André Franke 2003-08-28, 1:25 am |
| "John Agosta" <j_agosta@wideopenwest.kom> wrote:
>I find this discussion very interesting.
>Some thoughts are inserted, in-line....
>
This is indeed very interesting, especially since there are aspects we
didn't cover before, which seem to show that the point where error
recovery occures is not always the same.
>"André Franke" <dump.it@digital-filestore.de> wrote in message
> news:cluokvk7taiiviic5a6rml23j
tqinnr0cv@4ax.com...
>> Hansang Bae <uonr@alp.ee.pbz> wrote:
>>
>> >In article <f4d6f831.0308261643.611e618b@posting.google.com>,
>> >yannick@mail.opt.pf says...
>> >> [sender detects errors and resends, reciever does nothing]
>> >
>> >[NIC does CRC check but no ACK or NACK]
>>
>> [(ACK) transport layer is the first to sequence its PDUs]
>>
>
>The first layer that "numbers" its PDUs is not always layer 4.
>For example, LLC Type 2 will includes NS and NR sequencing, even when
>operating on an Ethernet medium.
>LLC type 2 isn't used for IP transmission, but it "does" exist for other
>protocols.
>Also, IP itself at layer 3 identifies each datagram with a number. Although
>the datagram ID is not used for
>error correction purposes - it is used for re-assembling fragmented
>datagrams. So within the context of
>(bit) error detection and correction, IP does not use sequence numbers for
>that purpose. However, IP
>does indeed number its PDUs for other purposes.
>
I agree that IP numbers its datagrams to be able to reassemble
fragments to transport layer segments. As you stated, again the
transport layer has to send a NACK if a segment can't be restored due
to lost IP packets resulting in missing fragments.
I further agree that LLC2 uses indeed ACKs and NACKs and it does so
even for error recovery. It just looks as if I'm mistaken.
But if you take a closer look at LLC2 you'll notice that this flow
control, error detection and recovery is kept on the LLC sublayer of
the datalink layer, namely for control purposes not for the host to
host communication but rather more to control the connection used for
host to host communication.
Within that context you could even say there is some kind of flow
control, error detection and recovery on the physical layer since a
delimiter is send as a row of bits to mark the start of a
transmission.
[colo
r=darkred]
>> >>[recieving router on serial links informs sending router, which resends]
>> >
>> >[routers don't resend, they don't store info, endstations do recovery]
>>
>>[(ACK) resending routers are proxies w/ routing, proxies are hosts]
>>
>
>Regarding who can 're-send,' the CSMA/CD standard for 1/2 dux ethernet does
>specify how
>the MAC sublayer can detect a collision, and attempt to re-access the medium
>to retransmit the frame.
>So, an ethernet NIC 'can' retransmit frames. It does not retransmit due to
>detecting corrupted frames / CRC events,
>but will retransmit in the event of contention for media access. Even a
>switch port operating in 1/2 duplex mode
>will retransmit when detecting collisions when attempting to access the
>medium.
>[/color]
This one is easy. If we agree that error recovery describes a process
in communication and communication involves at least two communicating
partners, a retry after backoff time in a CSMA/CD environment is not
an error recovery at all. The reciever didn't even notice that there
was some sender trying to address him. This is just as if you wanted
to tell me something but there is too much noise so that I don't even
notice you said something and you stop and try again and again without
speaking louder and without any chance to change the noise level.
>So the question of "who retransmits?" is ........"it depends."
>One cannot answer the question accurately unless the 'scenario-specific'
>context is being taken into consideration,
>IE - what protocols are being used, and what event "caused" the failure of
>the first transmission attempt.
>
There are no questions that can be answered straightly. You always
have to consider all the aspects of a problem. Your best bet is to
keep your terms straight and defined, so that not too much chances for
confusion are left over.
But remember: Doubts are friends, because if you have doubts if what
you seem to know is true, you can try to clear up what's unclear and
either strengthen your theories or refine or revise them to come
closer to the truth.
I really enjoy this discussion. Please don't stop.
regards
André
| |
| Ivan Ostres 2003-08-28, 3:26 am |
|
"mjm" <no_spam@sympatico.ca> wrote in message
news:k1b3b.10677$Cg2.845844@news20.bellglobal.com...
>
> If you have Host A that is connected to Switch A, and Host B that is
> connected to Switch B. Switch A and B are cross connected to each other
and
> configured for store and forward. If Host A sent a packet to Host B at
the
> exact same time that Host B sent a packet to Host A. The packets would be
> recieved by their corisonding switches at the same time. The switches
would
> then try to transmit the packet over the cross connect at the same time.
A
> collision would be detected. Now as the switches are store and forware,
> would they do their own retransmision because the cross connect is in it's
> own collision domain?
>
Hm.... I expect full duplex when cross-connecting switches, so... no
collision at all :-).
Ivan
| |
| John Agosta 2003-08-28, 1:25 pm |
|
"André Franke" <dump.it@digital-filestore.de> wrote in message
news:bpsqkvgqk39cdhs3vi63p0i72
mku08ih4g@4ax.com...
> "John Agosta" <j_agosta@wideopenwest.kom> wrote:
>
> >I find this discussion very interesting.
> >Some thoughts are inserted, in-line....
> >
> This is indeed very interesting, especially since there are aspects we
> didn't cover before, which seem to show that the point where error
> recovery occures is not always the same.
>
> >"André Franke" <dump.it@digital-filestore.de> wrote in message
> > news:cluokvk7taiiviic5a6rml23j
tqinnr0cv@4ax.com...
> >> Hansang Bae <uonr@alp.ee.pbz> wrote:
> >>
> >> >In article <f4d6f831.0308261643.611e618b@posting.google.com>,
> >> >yannick@mail.opt.pf says...
> >> >> [sender detects errors and resends, reciever does nothing]
> >> >
> >> >[NIC does CRC check but no ACK or NACK]
> >>
> >> [(ACK) transport layer is the first to sequence its PDUs]
> >>
> >
> >The first layer that "numbers" its PDUs is not always layer 4.
> >For example, LLC Type 2 will includes NS and NR sequencing, even when
> >operating on an Ethernet medium.
> >LLC type 2 isn't used for IP transmission, but it "does" exist for other
> >protocols.
> >Also, IP itself at layer 3 identifies each datagram with a number.
Although
> >the datagram ID is not used for
> >error correction purposes - it is used for re-assembling fragmented
> >datagrams. So within the context of
> >(bit) error detection and correction, IP does not use sequence numbers
for
> >that purpose. However, IP
> >does indeed number its PDUs for other purposes.
> >
> I agree that IP numbers its datagrams to be able to reassemble
> fragments to transport layer segments. As you stated, again the
> transport layer has to send a NACK if a segment can't be restored due
> to lost IP packets resulting in missing fragments.
TCP does not use negative acknowledgements. (NACK)
TCP transmitters use a timeout feature, and if a positive acknowledgement
is not received within a window of time that exists, the transmitter will
automatically re-transmit the 'segment.'
> I further agree that LLC2 uses indeed ACKs and NACKs and it does so
> even for error recovery. It just looks as if I'm mistaken.
> But if you take a closer look at LLC2 you'll notice that this flow
> control, error detection and recovery is kept on the LLC sublayer of
> the datalink layer, namely for control purposes not for the host to
> host communication but rather more to control the connection used for
> host to host communication.
> Within that context you could even say there is some kind of flow
> control, error detection and recovery on the physical layer since a
> delimiter is send as a row of bits to mark the start of a
> transmission.
>
I guess you 'could' say that, although I wouldn't.
I think debating that thought would just be nit-picking
so I'll stay away from that.
[colo
r=darkred]
> >> >>[recieving router on serial links informs sending router, which[/color]
resends]
> >> >
> >> >[routers don't resend, they don't store info, endstations do recovery]
> >>
> >>[(ACK) resending routers are proxies w/ routing, proxies are hosts]
> >>
> >
> >Regarding who can 're-send,' the CSMA/CD standard for 1/2 dux ethernet
does
> >specify how
> >the MAC sublayer can detect a collision, and attempt to re-access the
medium
> >to retransmit the frame.
> >So, an ethernet NIC 'can' retransmit frames. It does not retransmit due
to
> >detecting corrupted frames / CRC events,
> >but will retransmit in the event of contention for media access. Even a
> >switch port operating in 1/2 duplex mode
> >will retransmit when detecting collisions when attempting to access the
> >medium.
> >
> This one is easy. If we agree that error recovery describes a process
> in communication and communication involves at least two communicating
> partners, a retry after backoff time in a CSMA/CD environment is not
> an error recovery at all. The reciever didn't even notice that there
> was some sender trying to address him.
Error recovery, even 'bit error' recovery is not always part of a two-way
dialog. Simplex, uni-directional systems often incorporate Foward Error
Correction
(FEC) mechanisms allowing the receiver to detect and then correct bit errors
encountered during transmission. Some examples include early 3 out of 5
telex numbering,
LRC/VRC, and Reed-Solomon encoding, quite frequently used in RF / cellular
environments.
> This is just as if you wanted
> to tell me something but there is too much noise so that I don't even
> notice you said something and you stop and try again and again without
> speaking louder and without any chance to change the noise level.
>
I am not saying that a collision is an "error" event.
I am simply stating that the MAC functions do allow for 'retransmissions'
when contention on the medium (collisions) is detected. So I'm not debating
your point on this one. To do so would be nit picking, and besides, I tend
to
agree with what you said anyway given the context of the discussion.
> >So the question of "who retransmits?" is ........"it depends."
> >One cannot answer the question accurately unless the 'scenario-specific'
> >context is being taken into consideration,
> >IE - what protocols are being used, and what event "caused" the failure
of
> >the first transmission attempt.
> >
> There are no questions that can be answered straightly. You always
> have to consider all the aspects of a problem. Your best bet is to
> keep your terms straight and defined, so that not too much chances for
> confusion are left over.
> But remember: Doubts are friends, because if you have doubts if what
> you seem to know is true, you can try to clear up what's unclear and
> either strengthen your theories or refine or revise them to come
> closer to the truth.
>
> I really enjoy this discussion. Please don't stop.
>
> regards
> André
| |
| André Franke 2003-08-28, 1:25 pm |
| yannick@mail.opt.pf (YannickC) wrote:
>André could you give me the rfc number please.
I'm sorry if I confused you. I don't know of an rfc describing
CSMA/CD. The right source for CSMA/CD documents would be the
IEEE 802.3 working group.
http://grouper.ieee.org/groups/802/3/
I just wanted to point out that "silently discarded" is the RFC-term
related to what happens on lower layers, if errors are detected
regards
André
| |
| André Franke 2003-08-28, 2:25 pm |
| "John Agosta" <j_agosta@wideopenwest.kom> wrote:
>TCP does not use negative acknowledgements. (NACK)
>TCP transmitters use a timeout feature, and if a positive acknowledgement
>is not received within a window of time that exists, the transmitter will
>automatically re-transmit the 'segment.'
Ah, well, my fault
I should have known better, since I wrote myself:
>> [...]Your best bet is to
>> keep your terms straight and defined, so that not too much chances for
>> confusion are left over.
What I wanted to say was No ACK, which I used the wrong term NACK for.
Of course you are right, TCP doesn't employ any NACKs, it just doesn't
send an ACK for segments not arriving, which is indeed much simpler,
since there isn't to do anything at all  )
>>[could say "error correction even on physical layer"]
>
>I guess you 'could' say that, although I wouldn't.
>I think debating that thought would just be nit-picking
>so I'll stay away from that.
I agree.
>> This one is easy. If we agree that error recovery describes a process
>> in communication and communication involves at least two communicating
>> partners, a retry after backoff time in a CSMA/CD environment is not
>> an error recovery at all. The reciever didn't even notice that there
>> was some sender trying to address him.
>
>Error recovery, even 'bit error' recovery is not always part of a two-way
>dialog. Simplex, uni-directional systems often incorporate Foward Error
>Correction
>(FEC) mechanisms allowing the receiver to detect and then correct bit errors
>encountered during transmission. Some examples include early 3 out of 5
>telex numbering,
>LRC/VRC, and Reed-Solomon encoding, quite frequently used in RF / cellular
>environments.
It seems you know much more about that than I do, but wouldn't a FEC
be more like an error prevention or an insurance against errors?
I mean FEC in simple terms is just transmission of backup data, isn't
it? Isn't that just like shooting a shotgun, hoping to hit something?
And should we really consider that an error correction?
regards
André
| |
| John Agosta 2003-08-28, 3:25 pm |
|
"André Franke" <dump.it@digital-filestore.de> wrote in message
news:g2dskvcbcrp2ij3s448182ts4
lg05fonom@4ax.com...
> "John Agosta" <j_agosta@wideopenwest.kom> wrote:
>
> >TCP does not use negative acknowledgements. (NACK)
> >TCP transmitters use a timeout feature, and if a positive acknowledgement
> >is not received within a window of time that exists, the transmitter will
> >automatically re-transmit the 'segment.'
>
> Ah, well, my fault
> I should have known better, since I wrote myself:
>
> >> [...]Your best bet is to
> >> keep your terms straight and defined, so that not too much chances for
> >> confusion are left over.
>
> What I wanted to say was No ACK, which I used the wrong term NACK for.
> Of course you are right, TCP doesn't employ any NACKs, it just doesn't
> send an ACK for segments not arriving, which is indeed much simpler,
> since there isn't to do anything at all )
>
> >>[could say "error correction even on physical layer"]
> >
> >I guess you 'could' say that, although I wouldn't.
> >I think debating that thought would just be nit-picking
> >so I'll stay away from that.
>
> I agree.
>
> >> This one is easy. If we agree that error recovery describes a process
> >> in communication and communication involves at least two communicating
> >> partners, a retry after backoff time in a CSMA/CD environment is not
> >> an error recovery at all. The reciever didn't even notice that there
> >> was some sender trying to address him.
> >
> >Error recovery, even 'bit error' recovery is not always part of a two-way
> >dialog. Simplex, uni-directional systems often incorporate Foward Error
> >Correction
> >(FEC) mechanisms allowing the receiver to detect and then correct bit
errors
> >encountered during transmission. Some examples include early 3 out of 5
> >telex numbering,
> >LRC/VRC, and Reed-Solomon encoding, quite frequently used in RF /
cellular
> >environments.
>
> It seems you know much more about that than I do, but wouldn't a FEC
> be more like an error prevention or an insurance against errors?
> I mean FEC in simple terms is just transmission of backup data, isn't
> it? Isn't that just like shooting a shotgun, hoping to hit something?
> And should we really consider that an error correction?
>
> regards
> André
The "C" in FEC stands for "correction."
FEC mechanisms allow not only for the 'detection' of bit errors,
but the 'correction' of some of them, depending how many there are,
and in some cases where they may appear in the transmission block.
A very simple and early mechanism that was used in the 70s was combining
LRC with VRC in the FCS field.
I'll try to make an overly simple illustration of how it works....
Suppose we are using an "even parity" agreement, where the lef-most bit is
for parity purposes:
PDDDDDDD
Now, suppose there was a transmision of the ASCII characters ABCDEFG:
P1000001
P1000010
P1000011
P1000100
P1000101
P1000110
P1000111
When toggling the parity bit, we have horizontally:
01000001
01000010
11000011
01000100
11000101
11000110
01000111
Now let's also assign even parity vertically to the data:
01000001
01000010
11000011
01000100
11000101
11000110
01000111
-----------
11000000 = An additional character is formed representing (in this simple
example) the vertical parity.
Now, let's take the data and insert a SINGLE bit error (X).
01000001
01000010
11000011
01000100
110X0101 parity error somewhere in this row!
11000110
01000111
-----------
11000000
^ ---- parity error somewhere in this column!
The "0" that was in the X position is now a "1" due to a single bit error.
When doing the 'horizontal check, we can see that there is a parity failure
in the horizontal row with an X.
However, we do not know "where" the bit error is, or, how many there are. We
just know one exists.
When doing the vertical check, we know that there is an error in the 4th
column.
The bit that changed was at the intersection of the horizontal row and the
vertical column.
In this instance of a single bit error, the receiver can toggle the bad bit
to its proper value.
No need to reterun a "NAK" to the original transmitter.
If errors are detected, and we cannot identify 'where' there error is, then
we issue a NAK back to
the sending party.
The process is simple, but also not very reliable. It is possible to have
multiple bit errors, and not be able to
detect them using this simple parity scheme.
However, we can see that in this overly simplified example, a single bit
error can be detected and corrected
at the receiver's end without having to introduce re-transmissions and the
delay associated with re-transmitting.
This is a very primitive form of FEC.
In today's communications systems, we use much more sophisticated and
reliable mechanisms to perform
FEC functions. While the ability to "correct" transmission errors has
improved with time, the key issue is being 'reliable.'
IF there is a bit error, we want to know that fact. We do not want
'undetected' bit errors.
Isn't this fun?
| |
| André Franke 2003-08-28, 4:24 pm |
| "John Agosta" <j_agosta@wideopenwest.kom> wrote:
>
>I'll try to make an overly simple illustration of how it works....
>
Thank you for enlightening me
If you kindly permit, I add that to my archive.
It's quite interesting and the best thing is: I seem to understand it!
Indeed this is fun!
regards
André
|
|
|
|
|