From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Mon Jun 30 2003 - 20:10:01 GMT-3
At 6:14 PM -0400 6/30/03, Volkov, Dmitry (IDS Canada) wrote:
> > I'm not clear where you are going. First, fragmentation puts lots of
>> burden on the router, primarily processor but also memory, and also
>> (depending on platform) on the forwarding path.
>>
>> The router should never change DF. It should respond with ICMP when
>> there is a violation.
>
>Hmm, Maybe I missed something but as I said hosts send UDP/ICMP witth DF=0
>(I look via Sniffer and don't see opposite)
>("may fragment") It's why router in the middle doesn't respond with ICMP if
>packet "too big" but is doing
>defrag itself. It's why I changed DF bit on router to activate ICMP back and
>to avoid defrag on routers
>However host after it received icmp changed size properly but sending
>fragments
>
>However everything is fine with TCP (host sending DF=1)
>and PMTUD mechanism works fine
>
>> If the host is implemented reasonably, when it gets a fragmentation
>> failed, it should auto-adjust the MTU, perhaps a couple of times
>> until it stops getting ICMP 3 4. No burden on the router besides a
>> few ICMPs.
>
>Host, for UDP traffic, changes MTU properly but sending fragmets.
>No burden on routers but I don't understand why host fragments every paket
>assuming I send 1500 bytes
>into 2 fragments and continues to send it.
Let me be clear. Your host MTU is 1500. It receives an ICMP 3/4. You
are saying it generates true IP fragments, with the ID, offset, total
length, etc. fields properly set to create two segments of
approximately 700? bytes each?
Without checking the Host Requirements RFC, I don't think this is
required or even advisable behavior.
>Actually I used Lan traffic generator www.zti-telecom.com - to generate TCP
>and UDP traffic
>I'm wondring maybe here is the reason of such "strange" behavior. Anyway I
>sniffed different
>real UDP traffic and DF was always 0.
>
>>
>> >
>> >I don't know if RFC exists explaining that or it's just
>> vendor specific.
>> >I'm wondering if it's normal behavior. I'm looking for conceptual
>> >explanation.
>> >
>> >Probably because UDP/ICMP packets are "always" (i tested
>> with windows only)
>> >transmitted with "may fragment" - there is no reason for
>> host to participate
>> >in PMTU for udp/icmp traffic ?
>>
>> It's more fundamental than that. Every UDP transmission is a separate
>> event and should not depend on previous state in the host. Knowing
>> that you received ICMP 3 4 is previous state.
>
>Well, but TCP MSS is "negotiated" only within SYN, SYN-ACK packets
>lowest is winner. I think PMTU mechanism doesn't care about stateful nature
>of traffic.
>UDP has characteristic of flow (source/destin IP, ports) - it's pretty
>predictable as well.
"Predictable" is very different than "stateful". TCP maintains
considerable real-time information on every flow -- window sizes, ack
timers, credits, etc. UDP remembers nothing about the previous
packet in a flow or the state of the flow.
>So why it wouldn't work, regarding PMTUD, as TCP does. Why packets have DF=0
>?
>eliminating PMTUD from the scope.
Increasingly, I'm thinking you have a very strange host.
> > >
> > >> >Is it host/vendor depended or RFC ?
>> >>
>> >> If you think about it, it's architectural. TCP is stateful. UDP is
>> >> not. For UDP to consider a previous signal, that would mean it is
>> >> retaining state.
>> >
>> >Well, UDP stateless but again why to send fragments ;)
>>
>> I don't understand. Host UDP is stateless. IP decision-to-fragment is
>> also stateless.
>>
>> If the host application wanted to avoid fragmentation, its IP should
>> do route discovery, or set a conservative MTU.
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:11:15 GMT-3